[Seaside-dev] Seaside and exception behaviour

[Philippe Marschall]

2011/1/5 Alan Knight <knight at acm.org>:
> Hi All,
>    Here's something interesting that came up with respect to Seaside in
> VisualWorks. The basic symptom is that if you have an error in a component,
> in Squeak you would get a debugger in the web browser. In VisualWorks you
> would get a debugger coming up in the image, and it would be on a somewhat
> different stack, the actual error being an unhandled render notification.
> The root of this seems to be a difference in exception behaviour between
> Squeak/Pharo and VisualWorks.
>
>    The difference is a bit tricky to explain, so I'll also put in a code
> fragment that illustrates. Basically, if an exception is caught, and the
> handler block signals another exception, where does that exception begin
> looking for handlers. In VisualWorks, and in VisualAge, which are the only
> two I tested, it starts at the place it was raised. In Squeak and Pharo it
> appears that it starts at the, um, bottom again. This manifests in Seaside
> as
> ...
>   Generic Error handler
>     ...
>       WARenderNotificationHandler
>         ...
>           error
>
> So the error is raised, is caught by the generic error handler, and as a
> result it wants to display a debugger. Displaying a debugger wants to render
> a page, so it throws a WARenderNotification. But the only handler for that
> is further down in the stack, and so it's not caught. In Squeak and Pharo it
> appears that throwing that exception behaves more like resignalAs: behaves
> in VisualWorks (the resignalAs: method is a not yet implemented in
> VisualAge). Reading the ANSI specification, it's extraordinarily fuzzy about
> it, but I *think* it's describing the VisualWorks behaviour when it says
>
> If a matching handler is found, the exception action of the handler is
> evaluated in the exception environment that was current when the handler was
> created and the state of the current exception environment is preserved as
> the signaling environment.
>
> We think we can hack our way around that by specially coding Grease
> notifications to behave differently from other exceptions, but it's
> certainly not pretty, and it would be good if there was a cleaner way of
> dealing with it.
>
> To more concretely illustrate what I'm talking about, consider defining an
> exception class ExceptionOne. Then define a class First with a method
> startHere
>     "First new startHere"
>     [Second new doStuff] on: Error do: [:ex | Transcript cr; show:
> 'exception in startHere'. ExceptionOne signal].
>
> And a class Second, with
> doStuff
>     [self doMoreStuff] on: ExceptionOne do: [:ex | Transcript cr; show:
> 'Exception in doStuff'].
>
> and
>
> doMoreStuff
>     Transcript cr; show: 'Doing more stuff...'.
>     3 / 0.
>
> In VisualWorks and VisualAge that results in an uncaught ExceptionOne and a
> debugger. In Pharo 1.1 one-click it just prints 3 things to the Transcript,
> the same behaviour I'd get in VisualWorks if I change the startHere method
> to do "ex resiganlAs: ExceptionOne new"

Wow, you always learn something new. Please file an issue [1] and
don't hesitate to suggest a fix ;-)

 [1] http://code.google.com/p/seaside/issues/list

Cheers
Philippe