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

[Phil B]

Hernan,

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

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

Ah, now I understand.  I thought the smiley face was referring to our
previous thread where (I thought I remembered you stating) that you didn't
care for #return and so you were saying here effectively 'well if I don't
like what's already there, why would I want to add more to it?'  Yes,
communicating humor through text can be difficult!


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

I think I'm still not understanding your objection then.  Using Juan's
recent changesets to eliminate non-local returns in OMeta as an example,
why do you prefer that approach to using #methodReturn: within the
exception handler?  (I really do want to understand your objection)  To me,
the secondary/outer exception handler approach is more complex but more
importantly it bypasses Exception in the sense that you're telling
Exception 'yeah, yeah... everything is fine' when really it's not fine...
you're not fully handling the exception in the handler.


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

Yes... sort of :-)


> 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/371318c0/attachment-0001.htm>