[Seaside] VW WAWalkbackErrorHandler in 3.0

Julian Fitzell jfitzell at gmail.com
Tue Nov 9 09:48:12 UTC 2010


On Mon, Nov 8, 2010 at 4:29 PM, Bob N. <bobn at rogers.com> 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


More information about the seaside mailing list