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

[Hernan Wilkinson]

On Tue, Oct 15, 2019 at 1:00 AM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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',


the thing is that I don't see a problem :-)

BTW, what I really see as cumbersome is having to tell the exception
#return: or #resume: or #retry.
Conceptually that does not make sense, is not the exception that returns,
resumes neither retries, it is the block or collaboration that generated
the exception.
I think those messages should be sent to another object... but from the
semantics point of view, it does not make sense the receiver to be the
exception.
Or maybe the messages should be change to #returnFromBlockWith:,
#resumeCollaborationWith: and #retryBlock.

On the other hand, I just try this issue in other languages. In Ruby,
another language with non local returns, it works as it currently does in
Smalltalk. In Java, there is no non local return, but you can put a return
in an exc. handler and behaves correctly returning from the method that
contains the exc. handler.

Hernan.

> 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.
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191015/23b6f7b7/attachment.htm>