Revisiting the fix for nested exception handling

>
> Hi Nicolas,
>
> thanks for looking into this.
>
> 4 senders and 3 implementors of #reactivateHandlers isn't too bad. However, I miss an implementation of #deactivateHandlers. I suppose it is that new line in #handleSignal:? Would you mind adding that for readability? :-)
>
> Best,
> Marcel
>
> Am 11.04.2021 19:37:11 schrieb Nicolas Cellier <[hidden email]>:
>
> Hi all,
> In order to purge the inbox, I've been in the process of reviewing
> brainfuck code (a very slow process). While at it, I decided to
> revisit the solution for nested exception handlers (see
> testHandlerFromAction).
>
> There are two similar and obsolete fixes in the inbox (due to
> ContextPart->Context transition), Kernel-nice.857 and Kernel-fbs.870
> (backported from Cuis) that I moved to treated inbox for that reason.
> https://source.squeak.org/treated/Kernel-nice.857.diff
> https://source.squeak.org/treated/Kernel-fbs.870.diff
>
> Alas, those two solutions break the very peculiar expectations of
> testHandlerReentrancy. This is a pity, because to my knowledge, those
> expectations are essential for Tweak and Croquet.
>
> There was a previous attempt from Andreas which was more a simple hack
> in handleSignal:, that is to disable the handler by setting the temp
> variable handlerActive in on:do: to false (self tempAt: 3 put: false).
> I've generalized this solution.
> https://source.squeak.org/treated/Kernel-ar.540.diff
>
> However, there are several reasons why this does not work: the first
> one, objected by Julian Fitzell here
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-January/156453.html
> is that the handler must be able to handle a secondary exception
> raised by the defaultAction. We can find similar expectations with
> other exception handling, like resignalAs (I will publish another test
> soon).
>
> However, there is some simple strategy: before resuming the exception,
> scan the context stack a second time so as to rearm the exception
> handlers that we disabled during handleSignal:.
>
> The major drawback, is that I have to spread a few self
> reactivateHandlers here and there, virtually before every send of
> #resumedUnchecked:.
> The second drawback is that scanning the stack a second time is not
> the most economical solution, but I don't care too much, we have to
> make it right first.
>
> If you find the courage to review, or more easily just to test it,
> find it in the inbox...
> Oups, I accidentally published in trunk...
> Well the review will be forced, if you don't like it, admin please
> remove or revert.
> Sorry.
>
>