[Seaside-dev] Seaside and exception behaviour

[Paolo Bonzini]

On 01/05/2011 03:25 PM, Alan Knight wrote:
> 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"

FWIW GNU Smalltalk behaves the same as Squeak, independent of whether 
ExceptionOne inherits from Notification or Error.  The implementation 
was completely independent, FWIW.

The stack looks like

    #signal
    Handler for Error in #startHere
    #doMoreStuff
    #on:do: for #doStuff
    #doStuff
    #on:do: for #startHere (handler marked as busy)
    #startHere

When the search starts for the ExceptionOne handler, it will just search 
for a non-busy handler.  *Any* handler that is not busy will do.  In 
fact, if you have #on:do:on:do: you'll be able to execute the second 
handler while the first is running.

Modulo getting the semantics of #on:do:on:do: right, it shouldn't be 
hard to change GNU Smalltalk's behavior, and I'm curious if that will 
break its testsuite...

> the same behaviour I'd get in VisualWorks if I change the startHere
> method to do "ex resiganlAs: ExceptionOne new"

That's not exactly the same.  #resignalAs: will reinstate _all_ 
handlers, while GNU Smalltalk will only pick those that are above the 
currently running handler, and I think/hope Squeak does the same.

Paolo