You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
[email protected][email protected]
http://www.cincom.com/smalltalk
Original issue reported on code.google.com by [email protected] on 28 Jan 2011 at 8:19
The text was updated successfully, but these errors were encountered:
The only way to fix this is moving the error handler inside the render loop,
probably inside the session like it was in Seaside 2.8. We can even loop up the
same exception handler like the exception filter.
Original issue reported on code.google.com by
[email protected]
on 28 Jan 2011 at 8:19The text was updated successfully, but these errors were encountered: