Hello
I'm trying to understand the exact difference between using return: and not as a last statement of a on:do: block I read the excellent tests of ExceptionTester (Tx andreas they are cool). returning "self new returning" ^ [self firstActionSignalingAnError. self secondActionReturning42] on: Error do: [:ex | Transcript show: 'An error has occurred: ', ex messageText ; cr. ex return: 69] returning "self new returning" ^ [self firstActionSignalingAnError. self secondActionReturning42] on: Error do: [:ex | Transcript show: 'An error has occurred: ', ex messageText ; cr. 69] |
stephane ducasse wrote:
> Hello > > I'm trying to understand the exact difference between using return: and > not as > a last statement of a on:do: block There is none. Not using return: was less portable (VSE and GNU Smalltalk used resume: for the last statement if the exception is resumable), but with Seaside relying on the ANSI behavior many dialects are slowly changing. Paolo |
Paolo Bonzini wrote:
> stephane ducasse wrote: >> I'm trying to understand the exact difference between using return: >> and not as a last statement of a on:do: block > > There is none. Not using return: was less portable (VSE and GNU > Smalltalk used resume: for the last statement if the exception is > resumable), but with Seaside relying on the ANSI behavior many dialects > are slowly changing. Hm ... I don't quite recall but didn't ANSI specify that the behavior is undefined unless a specific handler response is invoked? In other words, *unless* you are specific about either #return: or #resume: the result may be implementation dependent? Cheers, - Andreas |
Andreas Raab wrote:
> Paolo Bonzini wrote: >> stephane ducasse wrote: >>> I'm trying to understand the exact difference between using return: >>> and not as a last statement of a on:do: block >> >> There is none. Not using return: was less portable (VSE and GNU >> Smalltalk used resume: for the last statement if the exception is >> resumable), but with Seaside relying on the ANSI behavior many >> dialects are slowly changing. > > Hm ... I don't quite recall but didn't ANSI specify that the behavior is > undefined unless a specific handler response is invoked? In other words, > *unless* you are specific about either #return: or #resume: the result > may be implementation dependent? No, though it is not explicitly defined as #return:. 5.4.3.3 Message: on: selector do: action [SNIP] If evaluation of the receiver terminates normally then the exception environment is reset to the handler environment before returning to the sender of the #on:do: message. If signaling of an exception results in evaluation of action the evaluation will occur in the context of the handler environment. The argument to the action will be an object that conforms to the protocol <signaledException>. 5.5.2.1 Message: signal [SNIP] If the evaluation of the exception action returns normally (as if it had returned from the #value: message), the handler environment is restored and the value returned from the exception action is returned as the value of the #on:do: message that created the handler. Before returning, any active #ensure: or #ifCurtailed: termination blocks created during evaluation of the receiver of the #on:do: message are evaluated. See also http://snipurl.com/33hyb [groups.google.com]. Paolo |
In reply to this post by Andreas.Raab
I read several times the ansi before posting and I could not find a
definitive answer. I thought that return: had to have something special to be worth its existence, but I could not find it. I thought that return: may clean the On Jul 23, 2008, at 7:25 AM, Andreas Raab wrote: > Paolo Bonzini wrote: >> stephane ducasse wrote: >>> I'm trying to understand the exact difference between using >>> return: and not as a last statement of a on:do: block >> There is none. Not using return: was less portable (VSE and GNU >> Smalltalk used resume: for the last statement if the exception is >> resumable), but with Seaside relying on the ANSI behavior many >> dialects are slowly changing. > > Hm ... I don't quite recall but didn't ANSI specify that the > behavior is undefined unless a specific handler response is invoked? > In other words, *unless* you are specific about either #return: or > #resume: the result may be implementation dependent? > > Cheers, > - Andreas > > |
Free forum by Nabble | Edit this page |