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

[Andres Valloud]

Just in case it wasn't clear... that I mentioned #nonLocalReturn: or 
some such did not mean I actually suggested doing that.  Action at this 
point seems premature to me.  This is why I was trying to focus on the 
problem definition first.

On 10/17/19 15:25, Hernan Wilkinson via Cuis-dev wrote:
> 
> 
> 
>             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 Wilkinson
>         Agile 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 Wilkinson
> Agile 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
>