[Cuis-dev] Exception handler blocks with non-local returns

[Andres Valloud]

Phil,

> Agreed and I think that's what I latched on to when you first raised the 
> issue.  This *could* cause some ugly problems down the road.  Just 
> because it doesn't currently doesn't mean it's not an issue as we might 
> not actually see a problem until some useful enhancement down the road 
> starts breaking things.

When I had to debug exception frameworks, the difficulty in verifying 
any changes were ok increased with heterogeneous usage, that's for sure.

Are we writing code to help others help us, or just to please ourselves? 
  What are the long term consequences of those two approaches?

> I'm with you as far as '^' usage in an exception handler block goes.  I 
> think where we have differing opinions is that I'm saying 'yes, let's 
> eliminate ^ from exception handler blocks'

I'd be ok with this, especially if the way the code gets reorganized 
makes changing the code further even easier next time.  It's also a nice 
exercise in awareness to see how horribly difficult it can be to change 
or even understand truly heterogeneous code.

> but at the same time saying 
> we should provide an explicit facility to allow for non-local returns 
> (i.e. #methodReturn or whatever.)  This accomplishes three things:
> 
> 1) Avoids potential issues down the road and/or being in the 
> uncomfortable position of not being able to implement a feature because 
> it will break code that could/should have been legitimately considered 
> broken before.
> 2) Provides a mechanism with equivalent functionality that we know will 
> *always* be correctly handled by the exception framework.
> 3) Makes the intent explicit (i.e. 'yes, I really did mean to do a 
> non-local return in this exception handler')

I can see that argument for the cases that remain after doing the 
cleanup you suggest.  Before I agree to this, though, I want to see a 
number of examples where there is really no better way to do things 
other than with non-local return (regardless of how it is actually 
expressed in code).

With these types of things, it's really important to keep options open 
and always verify one's assumptions with actual evidence along the way.

Here's an advantage of your suggestion I didn't see listed above: doing 
that would *define* what it means to do a non-local return in an 
exception handler block, and thus backfill a hole in section 5.5.2.1.

> I'm even in favor of saying 'from a best practices standpoint, we 
> recommend trying to avoid using #methodReturn' if we wanted to... just 
> provide it as an option.

Yeah, I can see this in general.  I'd even phrase it as "from a best 
practices standpoint, we recommend avoiding non-local returns in 
exception handler blocks, but if you choose to do that then using the 
#methodReturn: method provided for that effect helps the maintainers of 
the exception framework keep things working as intended because said 
method *defines* what it means to do a non-local return in this context".

But let's wait until we get there, and especially after we get a feel 
for the most difficult cleanup cases.  There's no need to put that down 
in stone right now.

> If we did that, then I have no problem in 
> flagging '^' in an exception handler as an error by default.  (Though we 
> would might still want to keep a preference option to not have it be an 
> error to help people porting code.)  It's taking away '^' without 
> providing an alternate way to do it, especially when it's so trivial to 
> do and logically consistent with the other functionality provided by the 
> framework, that I have a problem with.

Agreed, one should think about the users of the system.

> Let's use the Blue Book / ANSI 
> as a starting point, not the destination.

Agreed as well --- no need to get dogmatic over a document that is 20 
years old, we can all think independently.

So, action items... how about we go after the users of non-local returns 
in exception handler blocks and start cleaning them up piece meal?  We 
could start with that, see what remains after we deal with all the easy 
ones, and plan our next move.

Andres.