<div dir="ltr"><div dir="ltr">Andres,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 17, 2019 at 9:14 PM Andres Valloud via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">See below: the #nonLocalReturn: method is an illustration device to show <br>
that having to cross a method boundary allows flexibility and ease of <br>
maintenance that ^ does not.<br>
<br>
However, all of that is prefixed by "I would object less", rather than <br>
"I would stop objecting".<br></blockquote><div><br></div><div>If you're saying that one should generally try to avoid designs that necessitate non-local returns in exception handlers, I would agree with that. (with the caveat that they are actually avoided, and not just side-stepped)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The style of using non-local return in exception handlers, irrespective <br>
of how it happens, still has long term disadvantages.<br></blockquote><div><br></div><div>If you are using them in a 'control flow' use case (i.e. where the block is declared at its point of application), what problems to you anticipate?</div><div><br></div><div>Thanks,</div><div>Phil</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 10/14/19 21:02, Andres Valloud via Cuis-dev wrote:<br>
> The below argument seems to focus on how easy it is to write new code. <br>
> What I'm arguing is that the long term consequences of said code matter <br>
> even more.  IME, non-local returns in exception handler blocks are not <br>
> as beneficial as they initially seem to be.<br>
> <br>
> I would object less if exceptions understood a message such as #return: <br>
> that performed a non-local return.  At least then you can easily <br>
> breakpoint that, because if instead of<br>
> <br>
>      [:ex | ^5]<br>
> <br>
> the code reads<br>
> <br>
>      [:ex | ex nonLocalReturn: 5]<br>
> <br>
> then you can reimplement nonLocalReturn: *in the exception of interest <br>
> alone*, without breaking everything else.<br>
> <br>
> This is different from ^5 in a regular method because there the context <br>
> of ^5 is much more readily understood.  In an exception handler block, <br>
> at first glance you have no idea of where the exception might be coming <br>
> from, so what does ^5 mean in the context where the exception happened?<br>
><br>
</blockquote></div></div>