[Seaside-dev] Seaside and exception behaviour

[Alan Knight]

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"

-- 
Alan Knight [|], Engineering Manager, Cincom Smalltalk
knight at acm.org
aknight at cincom.com
http://www.cincom.com/smalltalk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20110105/b0fe43e4/attachment.htm