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

[Andres Valloud]

Hello,

> Andres, when you say:
> ---
> a) effectively, nobody is looking at how the exception handling
> mechanism is implemented, so doing non-local return like that curtails
> the private implementation of exception handling,
> ---
> The solution is to make the exception handling implementation aware of 
> this situation. As it is right now, it works correctly

Hang on: you're providing a 'solution', but the problem I'm pointing at 
is left unaddressed.  The issue here is that handler blocks end up 
depending on private implementation details, which means changing 
exception handling is more difficult.

> ----
> b) that kind of behavior is what the messages #return, #resume, #pass,
> #outer, etc are there for,
> ----
> Well , not really, non of them have the same semantics of non local return.

Right, I meant that's what *messages* are there for, such as #return, 
#resume, and so on.  Perhaps exceptions should be told to do a non-local 
return with a message, too.

> I do not see a problem in debugging something line [] on: Error do: [ ^5 
> ]. If I want to do it I would do this: [] on: Error do: [ ^5 halt ]

I was thinking of the long term consequences of writing code a certain 
way, and my experiences debugging exception handling itself (where, 
perhaps, there are places that cannot tolerate a non-local return). 
Code that is explicit about what is intended makes such work much easier 
(some people called that code 'intention revealing').

In contrast, using non-local returns creates dependencies on the 
particular flavor of exception handling you have.  Something similar 
happens with not telling the exception what you want done.

> Regarding confusing [] on: Error do: [ ^5 ] with [] on: Error do: [ :ex 
> | ex return: 5 ], that could happen with non local returns everywhere, 
> that is a problem of not knowing what non local returns really means, 
> not a problem on how to use exception handling...

I think we just have different perspectives.  When code gets really hard 
to understand, the work is often organized so that O(1) VM engineers 
debug O(n) problems.  That does not scale.

Andres.