<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        Hi Nicolas,<div class="mb_sig"></div>
                                        <div><br></div><div>thanks for looking into this.</div><div><br></div><div>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? :-)</div><div><br></div><div>Best,</div><div>Marcel</div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 11.04.2021 19:37:11 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi all,<br>In order to purge the inbox, I've been in the process of reviewing<br>brainfuck code (a very slow process). While at it, I decided to<br>revisit the solution for nested exception handlers (see<br>testHandlerFromAction).<br><br>There are two similar and obsolete fixes in the inbox (due to<br>ContextPart->Context transition), Kernel-nice.857 and Kernel-fbs.870<br>(backported from Cuis) that I moved to treated inbox for that reason.<br>https://source.squeak.org/treated/Kernel-nice.857.diff<br>https://source.squeak.org/treated/Kernel-fbs.870.diff<br><br>Alas, those two solutions break the very peculiar expectations of<br>testHandlerReentrancy. This is a pity, because to my knowledge, those<br>expectations are essential for Tweak and Croquet.<br><br>There was a previous attempt from Andreas which was more a simple hack<br>in handleSignal:, that is to disable the handler by setting the temp<br>variable handlerActive in on:do: to false (self tempAt: 3 put: false).<br>I've generalized this solution.<br>https://source.squeak.org/treated/Kernel-ar.540.diff<br><br>However, there are several reasons why this does not work: the first<br>one, objected by Julian Fitzell here<br>http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-January/156453.html<br>is that the handler must be able to handle a secondary exception<br>raised by the defaultAction. We can find similar expectations with<br>other exception handling, like resignalAs (I will publish another test<br>soon).<br><br>However, there is some simple strategy: before resuming the exception,<br>scan the context stack a second time so as to rearm the exception<br>handlers that we disabled during handleSignal:.<br><br>The major drawback, is that I have to spread a few self<br>reactivateHandlers here and there, virtually before every send of<br>#resumedUnchecked:.<br>The second drawback is that scanning the stack a second time is not<br>the most economical solution, but I don't care too much, we have to<br>make it right first.<br><br>If you find the courage to review, or more easily just to test it,<br>find it in the inbox...<br>Oups, I accidentally published in trunk...<br>Well the review will be forced, if you don't like it, admin please<br>remove or revert.<br>Sorry.<br><br></div></blockquote></div>