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

Hernan Wilkinson hernan.wilkinson at 10pines.com
Tue Oct 15 03:59:19 PDT 2019


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

hmm but then having that message add accidental complexity to the language.
With that, programmers have to know that when they want a non local return
in a exc. handler they can not use ^ like in any normal block but
#nonLocalReturn:
I think that extra complexity does not pay off in this case


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

Or you could know it and use the ^5 because you want to do that, exactly.
So, as far as I understand, you are questioning that people do not really
know what they do when they do ^5 in an exc. handler and I think that they
do know. Of course, beginners will make mistakes, but those mistakes are
the same of using non local returns in other places and they are necessary
to learn.


>
> 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
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*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/20191015/e6adb323/attachment-0001.htm>


More information about the Cuis-dev mailing list