Thanks. That's exactly why I wanted someone to review the approach. I'll 
go back to the drawing board and see if I can come up with something 
better :-)

Cheers,
   - Andreas

On 1/9/2011 9:47 PM, Julian Fitzell wrote:
> Hi Andreas,
>
> A neat approach, but I don't think it quite works (yet, anyway).
> Although it has the correct behaviour when the exception action is
> invoked, it doesn't behave correctly for #defaultAction. According to
> 5.5.2.1 in the spec, "The #defaultAction method is executed in the
> context of the signaling environment."
>
> So, taking an example of an existing #defaultAction method that
> signals an exception:
>
> [ Error signal ] on: UnhandledError do: [ :ex | 'ANSI says so' ]
>
> returns 'ANSI says so' without your change but brings up a debugger with it.
>
> Julian
>
> On Sat, Jan 8, 2011 at 7:34 PM, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> 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
>>>
>>>
>>
>>
>>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>