[Cuis-dev] Exception handler blocks with non-local returns
Andres Valloud
ten at smallinteger.com
Sat Nov 2 11:41:52 PDT 2019
Phil,
On 10/14/19 23:48, Andres Valloud via Cuis-dev wrote:
>> Taken together, I'd interpret that as any return value from the
>> handler block is a gray area and implementer's choice.
>
> IIRC, there's non-zero truth in this. But let's make sure, I'll do some
> more digging tomorrow.
The next to last paragraph in section 3.4.5.1 states that evaluating a
block with a non-local return results in the abnormal-termination of all
frames (the standard says 'functions') between the block's home context
and the block's evaluation. This is interesting for the following reason.
Of course, when one writes something like
1 = 1 ifTrue: [^#lalala]
irrespective of whether ifTrue: is optimized away, the net effect is
that ifTrue: had actually been sent, evaluating the block would throw
away the frame for ifTrue: and return from the method or expression
where [^#lalala] appears. That's ok because everybody knows ifTrue: is
meant to be used that way. Similar things happen with e.g.
1 to: 10 :: do: [:x | x isPrime: [^x]]
because everybody knows that do: has no side effects and is safe to
interrupt. You can verify this by looking at the implementation of do:,
and it is also the case that, typically, implementors of do: know that a
non-local return may appear in the received block and so nobody writes
do: to obstruct that usage.
Asking for the abnormal-termination of exception frames is a different
thing entirely. I can believe most people can recite the implementation
of do: from memory, but I would be really surprised if anyone could
write an exception framework from scratch without spending some serious
thought. In short, I think there's a huge familiarity gradient in play
here.
Further, section 5.5.2.1 says nothing of what happens if an exception
handler block has a non-local return, so the consequence might as well
be undefined (because, literally, it is not defined). (but if I missed
the spot where it's defined, I'd be happy to see what it says)
Given these, and from the experience debugging / fixing exception
frameworks over the years I mentioned earlier, I conclude that using
non-local returns in exception handler blocks is asking for trouble at
best, and undefined at worst. So, if I were to be the one writing code,
I would not use non-local returns in exception handler blocks.
I don't think I have much more to say about this.
Andres.
More information about the Cuis-dev
mailing list