[Glass] Exception stack and ajax [WAS] Re: Can't find Dale's seaside component for exploring Object Log
Mariano Martinez Peck via Glass
glass at lists.gemtalksystems.com
Sat May 30 08:37:38 PDT 2015
On Sat, May 30, 2015 at 12:00 AM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:
> Oh, good ... you _are_ interested in a continuation:)
>
yes!
>
> BTW, it does appear that in the WARemoteDebuggingWalkbackErrorHandler
> case, the errors are not logged to the gem log ... it is probably worth
> adding that capability since it isn't always a guarantee that the commit
> will succeed and logging to the gem log means that the error won't be lost
> forever ...
>
Exactly!!!! that was my conclusion: ajax exceptions end up in the
repository object log but NOT in the gem log text file, which is something
I would really like (as it happens with normal request exceptions).
> something like WAErrorHandler>>saveExceptionContinuation: could be called
> from WARemoteDebuggingWalkbackErrorHandler>>open: to log to the gem log AND
> save the continuation to the object log ...
>
>
But the save in the object log is already happening. If we call
#saveExceptionContinuation: would that be stored twice?
Do we know who is storing the continuation in the object log in case of an
ajax error?
Thanks Dale!
> Dale
>
>
> On 5/29/15 6:17 PM, Mariano Martinez Peck wrote:
>
> mmmm actually....I just checked again and it seems that if I click in the
> continuation link I do get the stack :) See attached screenshots.
> Cool! I think this answers my original question :)
> Thank you all....
>
>
> On Fri, May 29, 2015 at 9:53 PM, Mariano Martinez Peck via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>>
>>
>> On Fri, May 29, 2015 at 9:19 PM, Dale Henrichs via Glass <
>> glass at lists.gemtalksystems.com> wrote:
>>
>>>
>>> Let's see, GsProcess class>>stackReportToLevel: is the message used to
>>> dump the error to the gem log and you could add that to the console message.
>>>
>>> You could also arrange to log the error and stack by arranging to call
>>> GRGemStonePlatform>>logError:title:shouldCommit: and the stack would be
>>> logged to the gem log and the object log (presumably shouldCommit: should
>>> be false as you want to let the final commit before the response is called
>>> to do the work)...
>>>
>>> Then you'd have things covered three ways ...
>>>
>>> I also thought that the standard continuation error handling logic was
>>> triggered by ajax errors and continuations were snapped of for those errors
>>> as well ... but I don't see a sender for ajaxErrorHandler in my Seaside
>>> image, so perhaps that call is made instead of the call to the standard
>>> handler?
>>>
>>
>>
>> Dale,
>>
>> #ajaxErrorHandler is my own method (well, shared by Paul and I improved
>> it a bit). The sender of this method is part of my root/main application
>> component and does:
>>
>> html document
>> addLoadScript:
>> (html jQuery document
>> onAjaxError: (self ajaxErrorHandler
>> asFunction: #('event' 'jqxhr' 'settings' 'exception'))).
>>
>>
>> I just tried by commenting those lines, and I see not difference in
>> gemstone. I mean, I get the exception if I go to "DEbug" -> "Remote
>> Debugging" in GemTools. In addition, with the WAObjectLog I do see the
>> "resumable exception" and I can indeed see the "messageText" of the
>> exception.
>>
>> What I have no way to get is the full stack string (no matter if I set
>> or not my ajax error handler) without having to remote debug. I mean...I
>> need to get the full stack string without needing GemTools or similar.
>>
>> Note that the #ajaxErrorHandler is at client side from what I can see
>> so I am not sure how can I include there what you suggest
>> (#stackReportToLevel: and logError:title:shouldCommit: )
>>
>> I guess I am missing something...
>>
>> Thanks in advance!
>>
>>
>>
>>
>>>
>>>
>>> Dale
>>>
>>>
>>> On 5/29/15 4:49 PM, Mariano Martinez Peck via Glass wrote:
>>>
>>>
>>> BTW...let me ask something... In my seaside app, I have the remote
>>> debug error handler. So if I have an exception that is not cached anyway, I
>>> get to the nice seaside walkback with the typical buttons to remote debug,
>>> full stack etc. The problem I am having now is if the error happens as part
>>> of an ajax callback. In my case, I have an ajax error handler (pasted
>>> below). I get the browser popup saying "the program just broke" and
>>> everything. But I don't know how I can get the full stack of the error.
>>> Imagine the final user using the app. He receives such a popup. Now, me, as
>>> developer, how can I see the stacktrace of that error? My gemstone logs
>>> show nothing. The user has no way to click or copy paste the stack to send
>>> it to me.
>>>
>>>
>>> Thanks in advance (this was the original purpose of why I wanted to
>>> explore the object log).
>>>
>>>
>>>
>>>
>>> ajaxErrorHandler
>>> ^ ' if (jqxhr.status == 403) {
>>> alert("For security reasons we sign people out during
>>> periods of inactivity. Please sign in again.");
>>> window.location.href =
>>> settings.url.split("?")[0].replace("help","");
>>> } else {
>>>
>>> // This is on purpose because sometimes with TinyMCE we would get
>>> status 0 and empty error...when there was no error
>>> // The reason is explained in:
>>> http://bartwullems.blogspot.com.ar/2012/02/ajax-request-returns-status-0.html
>>> if (jqxhr.readyState == 0 || jqxhr.status == 0) {
>>> return; //Skip this error
>>> };
>>>
>>> // Lets write to console all error info possbile
>>> var requestResponse = {
>>> url: settings.url,
>>> method: settings.type,
>>> data: settings.data,
>>> httpStatus: jqxhr.status,
>>> error: exception || jqxhr.statusText,
>>> data: settings.data
>>> };
>>>
>>> console.error(requestResponse);
>>>
>>> alert("This program just broke. You can either try again,
>>> sign out and sign in and try again, or contact us about error: " +
>>> exception);
>>>
>>> }'
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Sebastian
>>>>
>>>>
>>>>
>>>> On 2015-05-29 2:16 PM, Mariano Martinez Peck wrote:
>>>>
>>>>
>>>>
>>>> On Fri, May 29, 2015 at 5:53 PM, Sebastian Heidbrink <
>>>> sebastian_heidbrink at yahoo.de> wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I am not 100% sure if this is what you are looking for, but it might
>>>>> include stuff related to this.
>>>>>
>>>>> http://seaside.gemtalksystems.com/ss/Naviode.html
>>>>>
>>>>
>>>>
>>>> THanks Sebastian, but it's not that one. The one I am talking about
>>>> is a very simply seaside app you can register and allows you to browse in a
>>>> kind of html table the entries of the object log. The app is also
>>>> pass-protected.
>>>>
>>>> Thanks anyway
>>>>
>>>>
>>>>>
>>>>>
>>>>> Sebastian
>>>>>
>>>>>
>>>>>
>>>>> Am 29.05.2015 um 13:40 schrieb Mariano Martinez Peck via Glass:
>>>>>
>>>>> Do you remember where is it? (the blog post)
>>>>>
>>>>> thanks in advance,
>>>>>
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>> _______________________________________________
>>> Glass mailing listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150530/0af11df1/attachment-0001.html>
More information about the Glass
mailing list