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

[Phil B]

Hernan,

On Tue, Oct 15, 2019 at 7:13 AM Hernan Wilkinson via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

>
>
> 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 :-)
>

Unfortunately, thanks to Andres, I now see it and it's hard to un-see.  And
you say that but then write this...


> 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.
>

Unless the intent of those methods is to transfer control to the
exception.  Assuming that is the case, was the intent that this transfer of
control be optional or mandatory?   It's entirely possible that this whole
issue boils down to 'the problem with blocks.'  So the question we have to
answer is: is it a feature, a bug with a feature, or a feature with a bug?


> 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.
>

... unless the intent was to transfer control.


> 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.
>

Keep in mind that most other languages blow up and die when you raise an
exception ;-)  And there are also languages that treat exceptions as an
explicit transfer of control where things like non-local returns would not
be allowed, if they even exist in the language.   Of course there's also
the age-old debate of why do exceptions exist and when should they be used
or not used.

But the issue isn't what do other languages do, it is more what do we want
Cuis to do?  Is it important that Cuis be/stay compatible with other
Smalltalk implementations on this front?  This has  obvious short term
impact to anyone's exception handling code both in terms of porting and
writing.   But it also has longer term implications for anyone making
changes that assume/depend on having control of execution as it relates to
enhancing the debugger, exceptions themselves or some other related
feature/capability.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191015/2e2f438d/attachment.htm>