[squeak-dev] The Inbox: Kernel-jar.1399.mcz

Jaromir Matas m at jaromir.net
Mon May 3 21:59:39 UTC 2021

Hi Jakob,

> One could argue that the return: message should not be sent to
> the Exception object when the exception action returns normally
> because that is not what it says in the specification of signal, and
> signal is not redefined by redefining return:.

Yes! I like this argument. I reopened this issue because it happened to me
that the two types of return didn't return to the same context - it means
one exception behaved as if it had two different handler contexts (it was
caused by a bug in #outer implementation and it's fixed now). I think both
returns should at least return to the same handler context if nothing else.

For lack of a more realistic scenario look at this example:

| x |
	[1/0] on: ZeroDivide do: [:ex | ex signal. ex return]. "handler 1"
] on: ZeroDivide do: [:ex | ex resume]. "handler 2"

----> answers '2' correctly because the active handler is handler 2.

However, if you replace ex return in handler 1 by the implicit return, it
all of a sudden answers '12' ! It's because #handleSignal invoked for
handler 1 returns to self (= handler 1) instead of to the exception's
handlerContext (=handler 2).

So actually, we don't need to send return to the exception to fix this, it
would suffice to use just the exception's handler context to return to -
what do you think? Here's what I mean:

handleSignal: exception
	"Sent to handler (on:do:) contexts only.
	Execute the handler action block"

	| val |
	<primitive: 199>  "just a marker, fail and execute the following"
	exception privHandlerContext: self contextTag.
	self deactivateHandler. "Prevent re-entering the action block, unless it is
explicitely rearmed"
	val := [self fireHandlerActionForSignal: exception] ensure: [self
---->	exception privHandlerContext return: val  	
	"return from exception's handlerContext if not otherwise directed in the
handler action block"

^[^ Jaromir
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

More information about the Squeak-dev mailing list