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

[Hernan Wilkinson]

Hi guys,
 I do not have to much time so I apologize for the short and direct opinion
on this matter.

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

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

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

Anyway, I understand your concern and I think the current solution, showing
a warning in the transcript, is the right one.

Cheers!
Hernan.

On Mon, Oct 14, 2019 at 4:04 AM Andres Valloud via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> On 10/13/19 21:36, Phil B wrote:
> > Andres,
> >
> > On Sun, Oct 13, 2019 at 10:51 PM Andres Valloud via Cuis-dev
> > <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> >
> >     Do we even agree this is a problem?
> >
> > I'd say there's a second question: If so, what do we do about it?
>
> Provided we agree there's a problem, we can consider that.  Part of what
> I'm trying to do here is to fully characterize the problem before coming
> up with solutions.  Otherwise, there is a risk that we will engage in
> so-called 'solutioning' (i.e. a beauty contest between solutions),
> instead of solving the problem.
>
> > I would agree it's a problem and that it's a question of how to handle
> > it.  I'm in favor of at least voluntarily minimizing the use of
> > non-local returns just to ensure expected debugger behavior regardless
> > of whether or not it's technically 'legal' and/or we effectively forbid
> it.
>
> Ok, but let's hear from others before deciding on a path forward.
>
> > One bit of feedback on this approach related to the last time we forbid
> > something this way: I still absolutely *hate* the exceptions for
> > shadowing variable names.  I find the mechanism annoying for something
> > that is a non-problem to me.  Others may feel that way about raising
> > exceptions for this issue.  I would much prefer that we handle issues
> > like these with some sort of opt-in linting/logging mechanism than
> > mandatory policy enforced by exceptions.
>
> I know nothing of this, I have no opinion.
>
> >     d) it's possible to distort the exception handling mechanism behavior
> >     with non-local returns.
> >
> > This one concerns me because we effectively have what appears to be a
> > 'legal' (in the sense that blocks can do it) end-run around the
> > exception mechanism.  Are there any examples of existing core code /
> > packages with subtle bugs because of this?
>
> I do not recall any specific instance of an actual bug because of this
> issue at this time.  I have a general recollection of seeing, many
> times, code that read along the lines of
>
>         [:ex | ^5]
>
> when it really meant
>
>         [:ex | ex return: 5]
>
> and the problem with it is that it's not debugging friendly.  That is,
> it's not that [:ex | ^5] itself caused a bug, but I was debugging around
> that and the non-local return made life harder than necessary.
>
> > Finally, does any literature (Blue Book, ANSI, previous discussion(s)...
> > whatever) specifically discuss do's/don'ts re: exception blocks or is it
> > just an ambiguous issue that was never delved into?  If anything does
> > exist, shouldn't we also consider it regarding how to proceed?
>
> Sure, we can look into that.
>
> 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/20191014/a0583d2e/attachment.htm>