[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