Seaside and exception behaviour

> 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
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> On 01/05/2011 04:08 PM, [hidden email] wrote:
> > Here's maybe a bit more concise example. If you run the thing below in a workspace,
> > it should return '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.

> > >  Here's maybe a bit more concise example. If you run the thing below in a workspace,
> > >  it should return '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'

> 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"

> On 01/05/2011 04:58 PM, [hidden email] 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.

> 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<[hidden email]>  wrote:
>>>
>>> On 01/05/2011 04:58 PM, [hidden email] 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
>>
>>
>
>
>

> 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<[hidden email]>  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<[hidden email]>    wrote:
>>>>
>>>> On 01/05/2011 04:58 PM, [hidden email] 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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> Here's maybe a bit more concise example. If you run the thing below in a workspace,
> it should return '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' ]
>
> HTH,
>
> Martin
>
> "Alan Knight"<[hidden email]>  wrote:
>> 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
>> [hidden email]
>> [hidden email]
>> http://www.cincom.com/smalltalk
>>
>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev