[Cuis-dev] On the changes to detect method returns in exception handlers

Phil B pbpublist at gmail.com
Thu Oct 17 12:12:28 PDT 2019


Hernan,

On Thu, Oct 17, 2019 at 1:59 PM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

> 1) Would you be opposed to a #nonLocalReturn: method on Exception?  That
>> seems to me a cleaner and clearer way of doing this.  It's also more
>> consistent with how Exception deals with the other scenarios.
>>
>>
>> I think #nonLocalReturn: would be ok. Maybe a better name could be
>> #methodReturn:
>>
>
> I'm against the #nonLocalReturn: or #methodReturn: :-)
> I think they do not solve anything (there is no problem currently) and
> they add accidental complexity that it is unnecessary.
>

I think the solution Juan provided illustrates the problem it would solve.
Since you can no longer perform a non-local return from an exception
handler, you need to clutter up your code with an ivar and some outer
logic... essentially making it a secondary exception handler.  How is
making the outer logic concern itself with what goes on inside an exception
handler simpler?

I understand that you don't like #return, #return: etc. but they do exist
and are intended to be used.  Not providing a mechanism to perform a
non-local return because you don't like the mechanism that already exists
for the other use cases seems to add (cognitive) complexity.  Since your
argument seems to stem from the fact that you don't like having to hand off
control to ex in [:ex| ex doThisForMe], how about instead making the case
for deviating from ANSI and eliminating all those other methods?  That at
least would be consistent.


> Cheers!
> Hernan
>
>

Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191017/f7875039/attachment.htm>


More information about the Cuis-dev mailing list