[Cuis-dev] On the changes to detect method returns in exception handlers
Hernan Wilkinson
hernan.wilkinson at 10pines.com
Thu Oct 17 14:04:12 PDT 2019
Hi Phil!
On Thu, Oct 17, 2019 at 4:12 PM Phil B <pbpublist at gmail.com> wrote:
> 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?
>
Just to clarify a bit my previous email... I wrote the ":-)" at the end of
the sentence because I knew the word "against" is too strong... It is so
difficult to express feelings on this medium, no, it is not difficult, it
is impossible!! :-)
>
> I understand that you don't like #return, #return: etc. but they do exist
> and are intended to be used.
>
hmm it is not that I do not like them as "we have to change them". My
comment about them was more "conceptual/design oriented" that a claim to
change them... it was just a comment to think about the matter. I use
#return and the other without problem. I do not think we have to change
that.
> 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.
>
We are desynchronized :-)
I'm sorry if I was not clear enough, it was not my intention to say that I
do not like what already exist.
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.
>
Well, I'm not against "having to hand off control to ex".
I hope I was more clear this time :-)
Cheers!
Hernan
>
>> Cheers!
>> Hernan
>>
>>
>
> Thanks,
> Phil
>
--
*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/20191017/e03c292d/attachment.htm>
More information about the Cuis-dev
mailing list