[Glass] Exception stack and ajax [WAS] Re: Can't find Dale's seaside component for exploring Object Log

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

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 <[hidden email]> 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 list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Oh, good ... you _are_ interested in a continuation:)

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 ...

something like WAErrorHandler>>saveExceptionContinuation: could be called from WARemoteDebuggingWalkbackErrorHandler>>open: to log to the gem log AND save the continuation to the object log ...

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 <[hidden email]> wrote:

On Fri, May 29, 2015 at 9:19 PM, Dale Henrichs via Glass <[hidden email]> 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 <[hidden email]> 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 list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

Okay....

In WARemoteDebuggingWalkbackErrorHandler>>open: there is a test for isXmlHttpRequest which is there to differentiate between html responses and AJAX responses IIRC and it responds with WAResponseGenerator>>internalError:...It looks to me like a continuation _is_ created and stored in the object log, but I take it you aren't necessarily interested in that route ...

Sooo, I would say that you would want to customize WAResponseGenerator>>internalError: to include a stack trace in the response using GsProcess class>>stackReportToLevel: .... it's probably worth verifying that WAResponseGenerator>>internalError: is the one generating the response, but reading the code it looks like it's the one that must be doing that ... You might want to return a structured response so that you client could produce a bit better output or even display the error and stack to the user in some form...

Dale

On 5/29/15 5:53 PM, Mariano Martinez Peck wrote:

On Fri, May 29, 2015 at 9:19 PM, Dale Henrichs via Glass <[hidden email]> 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 <[hidden email]> 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 list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--

Mariano
http://marianopeck.wordpress.com

On 05/30/2015 08:37 AM, Mariano Martinez Peck wrote:

On Sat, May 30, 2015 at 12:00 AM, Dale Henrichs <[hidden email]> 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?

It looks like WARemoteDebuggingWalkback>>addContinuation is the spot where the continuation is being saved to the object log and there is nothing written to the gem log there, so the call to add a message to the gem log needs to be added in WARemoteDebuggingWalkbackErrorHandler>>open: ... I've got a proposed fix up on github[1].

Please take a look (others as well) and perhaps comment on the changes before I push them out to gs_master... It would be nice if you could verify that I've pinpointed the right spot...