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

Hernan Wilkinson hernan.wilkinson at 10pines.com
Thu Oct 17 15:25:54 PDT 2019


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

I prefer using the normal ^ instead of #methodReturn: because:
1) currently, using the ^ in an exc. handler works correctly and does not
break the exception mechanism
2) doing a non local return using the #methodReturn: message instead the ^,
adds a new way of doing the same thing as ^, so it adds accidental
complexity and redundancy that it is not really needed because of 1)
3) because of 2), now we have to teach beginners that when in an exc.
handler, and only there, they have to use #methodReturn: to do a non local
return, making the language more difficult to understand
4) it breaks compatibility with other Smalltalks because of something that
currently, is not a problem.

So, that is basically it... I do not see a real advantage doing this.

Cheers!
Hernan.


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

-- 

*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/9bfcfe6a/attachment.htm>


More information about the Cuis-dev mailing list