<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi All,<br>
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.<br>
<br>
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<br>
...<br>
Generic Error handler<br>
...<br>
WARenderNotificationHandler<br>
...<br>
error<br>
<br>
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 <br>
<style>@font-face {
font-family: "Arial";
}p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm 0cm 0.0001pt; font-size: 10pt; font-family: "Times New Roman"; }p.ProtocolParagraph, li.ProtocolParagraph, div.ProtocolParagraph { margin: 3pt 0cm 0.0001pt 28.8pt; font-size: 10pt; font-family: "Times New Roman"; }div.Section1 { page: Section1; }</style>
<p class="ProtocolParagraph">If a matching handler is found, the <i
style="">exception action</i> of the handler is
evaluated in the <i style="">exception environment</i>
that was current when the handler was created and the state of the
current <i style="">exception environment</i> is preserved as
the <i style="">signaling environment</i>.</p>
<br>
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.<br>
<br>
To more concretely illustrate what I'm talking about, consider
defining an exception class ExceptionOne. Then define a class First
with a method <br>
startHere<br>
"First new startHere"<br>
[Second new doStuff] on: Error do: [:ex | Transcript cr; show:
'exception in startHere'. ExceptionOne signal].<br>
<br>
And a class Second, with<br>
doStuff<br>
[self doMoreStuff] on: ExceptionOne do: [:ex | Transcript cr;
show: 'Exception in doStuff'].<br>
<br>
and <br>
<br>
doMoreStuff<br>
Transcript cr; show: 'Doing more stuff...'.<br>
3 / 0.<br>
<br>
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"<br>
<br>
<pre class="moz-signature" cols="72">--
Alan Knight [|], Engineering Manager, Cincom Smalltalk
<a class="moz-txt-link-abbreviated" href="mailto:knight@acm.org">knight@acm.org</a>
<a class="moz-txt-link-abbreviated" href="mailto:aknight@cincom.com">aknight@cincom.com</a>
<a class="moz-txt-link-freetext" href="http://www.cincom.com/smalltalk">http://www.cincom.com/smalltalk</a></pre>
</body>
</html>