On Wed, Jan 5, 2011 at 8:15 AM, Paolo Bonzini <bonzini at gnu.org> wrote:
> On 01/05/2011 04:58 PM, mkobetic at cincom.com wrote:
>>
>> > >  Here's maybe a bit more concise example. If you run the thing below
>> > > in a workspace,
>> > >  it returns 'Squeak' in Squeak and 'VW' in VW
>> > >
>> > >  [  [       [       self error: 'trigger error'
>> > >             ] on: ZeroDivide do: [ :ex | 'Squeak' ]
>> > >     ] on: Error do: [ :ex | 3 / 0 ]
>> > >  ] on: ZeroDivide do: [ :ex | 'VW' ]
>> >
>> >  It returns 'Squeak' on GNU Smalltalk.  This is consistent with my
>> >  analysis of Alan's snippet.  Unfortunately I don't have at hand my copy
>> >  of the standard.
>>
>> FWIW, Smalltalk/X returns 'VW'
>
> That's the correct behavior.  The standard says the search should proceed
> from the last exception handler that was created up to the oldest.

Agreed.  The ANSI standard seems quite clear about that:

5.4.3.3: "If signaling of an exception results in evaluation of action
the evaluation will occur in the context of the handler environment."

5.5.2.1: "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."

> (That said, Squeak/gst's behavior is quite easy to justify, as stack
> unwinding hasn't happened yet.  I'll wait for this thread to settle before
> changing it in gst).

But stack unwinding shouldn't need to happen until one of the #on:do:
calls is actually ready to return. Until then, its all just searching.

I think Squeak/Pharo's problem is that it doesn't maintain a first
class "exception environment" as described by the glossary in the ANSI
standard: "An abstract entity that is a LIFO list of exception
handlers. An exception environment may be logically searched starting
from the most recently "pushed" exception handler."

Squeak/Pharo simply (ab)uses the context chain, walking it looking for
the next handler (see the implementation of #signal, which always
starts searching from thisContext). This works fine most of the time
but not when you need to temporarily restore a previous exception
environment. #handleSignal: does go to the effort of setting a
handlerContext on the signaled exception before calling the action
block. This is necessary to implement #pass, #isNested, and so on but
would also need to be put somewhere that #signal could get at it to
use as a starting point for the search.

This seems like a squeak/pharo bug to me. I don't much feel like
fixing it in Grease given that Grease is supposed to assume correct
ANSI implementation as a pre-requisite. Perhaps we can broker a deal
where Squeak/Pharo will fix this and VW (finally) fixes its signaling
behaviour so we can drop GRError, etc. entirely.

In the meantime, though, how would we fix the Seaside code assuming we
had ANSI-correct exception handling implementations?

Julian