[Cuis-dev] [Ann] Refinements to Exception handling

Andres Valloud ten at smallinteger.com
Thu Oct 17 18:14:26 PDT 2019


See below: the #nonLocalReturn: method is an illustration device to show 
that having to cross a method boundary allows flexibility and ease of 
maintenance that ^ does not.

However, all of that is prefixed by "I would object less", rather than 
"I would stop objecting".

The style of using non-local return in exception handlers, irrespective 
of how it happens, still has long term disadvantages.

On 10/14/19 21:02, Andres Valloud via Cuis-dev wrote:
> The below argument seems to focus on how easy it is to write new code. 
> What I'm arguing is that the long term consequences of said code matter 
> even more.  IME, non-local returns in exception handler blocks are not 
> as beneficial as they initially seem to be.
> 
> I would object less if exceptions understood a message such as #return: 
> that performed a non-local return.  At least then you can easily 
> breakpoint that, because if instead of
> 
>      [:ex | ^5]
> 
> the code reads
> 
>      [:ex | ex nonLocalReturn: 5]
> 
> then you can reimplement nonLocalReturn: *in the exception of interest 
> alone*, without breaking everything else.
> 
> This is different from ^5 in a regular method because there the context 
> of ^5 is much more readily understood.  In an exception handler block, 
> at first glance you have no idea of where the exception might be coming 
> from, so what does ^5 mean in the context where the exception happened?
> 
> On 10/14/19 04:17, Hernan Wilkinson wrote:
>> I checked and the exception handling mechanism is not affected by a 
>> non-local return in an exception handler, it works fine.
>> I think that having a non local return in an exc. handler is really 
>> handy and I do not see the problem with that really. Of course that 
>> people can make mistakes but that is related to not using non local 
>> returns correctly, not to doing it in the exc. handler.
>> The #return:, #pass, etc. do no have the same behavior as having a non 
>> local return... with this change if I want to return from the method 
>> when handling an exception a special object will have to be returned 
>> and the a check with an if for it will be needed.
>>
>> I think this change is a step backwards really, it makes things harder 
>> for handler you want to return from the method and having a non local 
>> return does not harm how exceptions work.
>>
>> Hernan.
>>
>> On Sun, Oct 13, 2019 at 5:12 PM Andres Valloud via Cuis-dev 
>> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
>>
>>     The conversation that led to these changes went more or less like
>>     this... first, I noted that exception handlers that look like this:
>>
>>              [:ex | ^5]
>>
>>     are asking for trouble, because:
>>
>>     a) effectively, nobody is looking at how the exception handling
>>     mechanism is implemented, so doing non-local return like that 
>> curtails
>>     the private implementation of exception handling,
>>
>>     b) that kind of behavior is what the messages #return, #resume, 
>> #pass,
>>     #outer, etc are there for,
>>
>>     c) when you need to debug why exceptions are behaving a certain way,
>>     the
>>     above exception handlers make debugging impossible because now 
>> there's
>>     no place to put a breakpoint (e.g. in #return, #resume, #pass, 
>> #outer,
>>     etc, which can be redefined for the purpose at hand in the single
>>     exception of interest), and finally,
>>
>>     d) it's possible to distort the exception handling mechanism behavior
>>     with non-local returns.
>>
>>
>>     The vast majority of the time, I see exception handlers with 
>> non-local
>>     returns as very close to expressions such as these:
>>
>>              #(1 2 3) asSortedCollection: [:x :y | ^x < y]
>>
>>     where the behavior you get is not what you expected, even though the
>>     code is doing exactly what was requested.  See attached for an actual
>>     example of what I mean.  To run the code, do these and see what 
>> happens.
>>
>>              ExceptionExample new breakingStuff
>>              ExceptionExample new workingStuff
>>
>>     To me, generally speaking, these considerations push the scales 
>> against
>>     the apparent convenience of having exception handlers do a non-local
>>     return.  I do not want to have to debug that kind of convenience 
>> under
>>     time pressure.  I do not even want to have to change code that uses
>>     such
>>     convenience, because it's going to be more difficult than otherwise.
>>
>>
>>     So Juan heard this and pointed out the reasoning is lovely but 
>> it's not
>>     that helpful because the system is doing nothing to make users 
>> aware of
>>     these facts.  He suggested the system should complain instead.  
>> Thus we
>>     (although he says mostly I) wrote code that detects non-local return
>>     and
>>     complains.  I believe that code was integrated recently (this bit, he
>>     did on his own LOL).
>>
>>     Andres.
>>
>>     On 10/13/19 07:52, Hernan Wilkinson wrote:
>>      > Could you provide the case were it generates problems?
>>      >
>>      > On Sun, Oct 13, 2019 at 11:40 AM Hernan Wilkinson
>>      > <hernan.wilkinson at 10pines.com
>>     <mailto:hernan.wilkinson at 10pines.com>
>>     <mailto:hernan.wilkinson at 10pines.com
>>     <mailto:hernan.wilkinson at 10pines.com>>> wrote:
>>      >
>>      >     Hi,
>>      >       I think that forbidden a non local return in an exception
>>     handler
>>      >     is not really the solution... Although I understand the
>>     motivation I
>>      >     think that changing the exception handling mechanism would be
>>     better.
>>      >       I'm going to take a look at it to see if it is possible to
>>     do it.
>>      >
>>      >     Hernan.
>>      >
>>      >     On Sun, Oct 13, 2019 at 10:48 AM Juan Vuletich via Cuis-dev
>>      >     <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>
>>     <mailto:cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>>> 
>> wrote:
>>      >
>>      >         Hi Folks,
>>      >
>>      >         Some time ago, Andrés (with just a tad of help from me)
>>     fixed a
>>      >         problem
>>      >         in Exception handling. If exception handler blocks do
>>     non-local
>>      >         return
>>      >         (^stuff), they will skip execution of part of the 
>> Exception
>>      >         handling
>>      >         system code, breaking exception return values and
>>     possibly other
>>      >         'bad
>>      >         things'.
>>      >
>>      >         I just pushed to GitHub a few updates with this work.
>>     Now, if an
>>      >         exception handler does a non-local return, an Error 
>> will be
>>      >         raised. We
>>      >         also fixed a couple of places in the image where this was
>>     being
>>      >         done.
>>      >         BaseImageTests pass.
>>      >
>>      >         This updates have some risk of breaking your code. If 
>> you you
>>      >         get this
>>      >         error: 'Exception handler blocks must not do non local
>>     returns',
>>      >         then
>>      >         you need to adjust your code. See updates #3917 to #3922
>>     for the
>>      >         changes
>>      >         done to the base image.
>>      >
>>      >         Thanks,
>>      >
>>      >         --
>>      >         Juan Vuletich
>>      > www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
>>     <http://www.cuis-smalltalk.org>
>>      > https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>>      > https://github.com/jvuletich
>>      > https://www.linkedin.com/in/juan-vuletich-75611b3
>>      >         @JuanVuletich
>>      >
>>      >         --
>>      >         Cuis-dev mailing list
>>      > Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>>     <mailto:Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>>
>>      > https://lists.cuis.st/mailman/listinfo/cuis-dev
>>      >
>>      >
>>      >
>>      >     --
>>      >     *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
>>     --     Cuis-dev mailing list
>>     Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>>     https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>>
>>
>> -- 
>> *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


More information about the Cuis-dev mailing list