[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