[Glass] How to remote debug exceptions caused by seaside rendering?

[Dale Henrichs via Glass]

Mariano,

Debugging the ajax calls is a bit problematic because the ajax response 
is in XML and arbitrary xml (which is what is done for the html 
debugger) is not an acceptable response ...

Anyway ... I would like to see more of the error stack specifically the 
first couple of frames of the process.

When the debugger is being opened on an error continuation, we basically 
`execute` the continuation using #debug as the value. The error handling 
code inserts code that opens a debugger when the value is #debug and 
voila the debugger is opened.

In your particular case it LOOKS like the continuation was put into the 
object log without the special debug code and the error you are getting 
is the result of `executing` the continuation without the benefit of the 
proper session handlers wrapped around...

BUT, I need to see the full stack or at the least the bottom of the 
stack to confirm ...

Finally, could you point me to the code where the ajax handler resides? 
It's been a while since I've been in that part of the code and frankly I 
recall that there was a problem with error handling for ajax, but I 
don't  recall actually doing anything about it ... so a pointer will 
help ... if I don't find what I think I am looking for:)

Dale

On 04/24/2015 08:45 AM, Mariano Martinez Peck via Glass wrote:
> Hi guys,
>
> I think that at some point this worked for me... but it doesn't 
> anymore...  I have a seaside app and it is using the 
> WAGemsToneWalkbackErrorHandler. I have an ajax request  that it seems 
> to be causing a walkback. Since it is an ajax call, I do not even 
> receive the walkback page where it shows the stack and I have the 
> buttons "remote debug", "full stack" , etc. Instead.... I have a new 
> entry in the Object Log. In other words, in GemTools I go to "Debug" 
> and I see the exception there. THERE in the list, I can see the real 
> error..for example "MessageNotUnderstood ocurred (error 2010), a Set 
> does not undersntand #'on:'".   However, when I click in the exception 
> so that to open a debugger, the debugger cannot open the stack because 
> it always fails to get the Seaside context (#session answers nil and 
> therefore I get another new MNU about this). See attached screenshot.
>
> So... the questions is:
>
> 1) In the ideal world, I would like to debug it.
> 2) If I am not in the ideal world, then at least I would like to see 
> the stack of the exception. Right now I cannot see ANYTHING... all I 
> know is Set dnu #on:   so yeah, probably a class I don't have a in 
> GemStone that is getting a class side #on:
>
> Any idea how can I make this to work?
>
> ps: I have native code enabled. This is in a CentOS machine. I am 
> using latest GemStone 3.1 and latest Seaside.
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150424/3d53f01e/attachment.html>