Thanks for the test case. I've posted a possible fix for Squeak to the 
inbox (Kernel-ar.540) but I'd like people to review the change first 
since it's a fairly critical part of the system. I'd appreciate if 
someone could look at the fix and comment on whether that's the sensible 
thing to do.

Cheers,
   - Andreas

On 1/8/2011 6:02 PM, Julian Fitzell wrote:
> 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
>
>