VW WAWalkbackErrorHandler in 3.0
Locked
 
|
(I suspect this question has already been answered, but none of my searches have found it).
We're moving some of our production Seaside code to VW Seaside 3.0 and I'm tripping over the exception handler.
Q: how do you add a custom exception hander to Seaside in VW? In... WAWalkbackErrorHandler>>open: ...the code wraps an exception hander around... self session presenter call: (WAWalkback current exception: anException).
...which in VW raises a WAUnhandledNotificationError exception. This is then handed off to the super class to send... GRPlatform current openDebuggerOn: anException ...which opens a debugger on the server (fine for development work).
Selecting 'run' in the debugger will then render the WAVisualWorksWalkback (subclass of WAWalkback) component. The exception is raised in... WARenderNotification>>defaultAction
^ WAUnhandledNotificationError signalWithNotification: self ...which is not an area of Seaside I spend any time in (and many thanks all those who's work allows me to wallow in ignorance of that code).
In Pharo, the WAUnhandledNotificationError exception is not raised, so adding our own exception hander is trivial. I've tested this in VW 7.7 with the latest Seaside loaded...
(3.0 - 85,mlucas-smith) On: 9/21/10 1:19:37 AM 61114: "Port Seaside 3.0 final TO VW 7.8" Thanks for any help, Bob Nemec _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
Re: VW WAWalkbackErrorHandler in 3.0
|
|
On Mon, Nov 8, 2010 at 4:29 PM, Bob N. <[hidden email]> wrote:
> (I suspect this question has already been answered, but none of my searches > have found it). > We're moving some of our production Seaside code to VW Seaside 3.0 and I'm > tripping over the exception handler. > Q: how do you add a custom exception hander to Seaside in VW? Just subclass WAExceptionHandler and specify the subclass in the application's configuration. > In... > WAWalkbackErrorHandler>>open: > ...the code wraps an exception hander around... > self session presenter call: (WAWalkback current exception: > anException). > ...which in VW raises a WAUnhandledNotificationError exception. This is > then handed off to the super class to send... > GRPlatform current openDebuggerOn: anException > ...which opens a debugger on the server (fine for development work). > Selecting 'run' in the debugger will then render the WAVisualWorksWalkback > (subclass of WAWalkback) component. > The exception is raised in... > WARenderNotification>>defaultAction > ^ WAUnhandledNotificationError signalWithNotification: self > ...which is not an area of Seaside I spend any time in (and many thanks all > those who's work allows me to wallow in ignorance of that code). > In Pharo, the WAUnhandledNotificationError exception is not raised, so > adding our own exception hander is trivial. I'm not too sure what's going on there. Currently in 3.0 we have a problem that if you hit an error while rendering, the error handler cannot use #call:. So this triggers an error which is caught in #open:, as you point out, and falls back to the (non-calling) superclass behaviour. It sounds like you are not in a render phase when hitting your error, though, since a WARenderNotification is being signaled. Signaling that notification is completely normal and happens at the end of more or less any action phase to indicate that a new render pass should begin. This is normally caught by WARenderLoopContinuation>>withNotificationHandlerDo: so the question is, why is the VW implementation not doing so? Michael may be able to shed some light or maybe you can determine more by looking further up your context chain... Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Evidently, that's just the way it is (we opened a case with Cincom, 424170). Exception handling is handled well by WebVelocity but that code will not be ported to their Seaside implementation. Unless I'm missing something, subclassing WAExceptionHandler in VW is of little use since WAUnhandledNotificationError will be raised when the exception handler is called, and that opens a debugger on the server.
It's easy to see the difference between Pharo and VW using something like...
renderContentOn: html html form: [ html button callback: [self error: 'This is only a test']; with: 'Press for error']
In VW, this opens a debugger on the server. If you then press 'run' you'll see a stack trace on the browser. In Pharo, this renders a stack trace on the browser, and if you press 'debug' it opens a debugger on the server.
I'd love to know how others have worked around this. Thanks, Bob <...> It sounds like you are not in a render phase when hitting your error, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |