Hi Jaromir,<br>
<br>
> Yes, I was wondering why I couldn't get rid of the duplication and now I think it's because there really are two distinct unwind semantics : one "light" for regular returns and one "heavy" for termination. Both are very similar yet each require a slightly different behavior - that's why the duality #runUntilErrorOrReturnFrom / #runUnwindUntilErrorOrReturnFrom or #complete: / #complete:to: and #unwindTo: / #terminate.<br>
<br>
But they are still pretty similar ... Couldn't you just add some extra parameter to these message? E.g., "Context runUntilErrorOrReturnFrom: aggressive"? I have the feeling that we could eliminate significant duplication that way by inserting some ifs and elses ... Duplicated code very often tends to be harder to maintained.<br>
<br>
> With regards to #unwindTo: - I haven't tested it yet but I'm wondering whether it wouldn't have the same unwind problem with non-local returns as the original #terminate and require a similar fix?<br>
<br>
Hm, do we need to implement both modi - (ii) and (iii) as described in [1] - in Context >> #unwindTo: as well? Something like #unwindTo:aggressive:?<br>
<br>
> But in general - yes, any method/exception purposefully (or not) written to create a loop will break this patch (I admit it is just a patch really). I extracted it to #complete:to: to make #terminate clean; this is a WIP; I wish there was a holistic solution to this - maybe checking for exception recursion by default? :)<br>
<br>
Sounds better already, if feasible! But how would you detect this? Unfortunately I've lost track of these infinite loops - could you maybe point me to some concrete examples that lead to an infinite recursion without this special check? :-)<br>
<br>
<br>
One more question about your #<font color="#FF0000">runUnwindUntilErrorOrReturnFrom:</font> Are you maybe missing something like "cxt terminate" in the "No error was raised" case? Just wondering.<br>
<br>
Best,<br>
Christoph<br>
<br>
[1] http://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-during-process-termination-tp5129800p5130110.html<br>
<br>
<font color="#808080">---<br>
</font><i><font color="#808080">Sent from </font></i><i><u><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><font color="#808080">Squeak Inbox Talk</font></a></u></i><br>
<br>
On 2021-05-31T17:01:46-05:00, m@jaromir.net wrote:<br>
<br>
> Jaromir Matas wrote<br>
> > Hi All,<br>
> > I've sent an updated version of #teminate integrating Christoph's solution<br>
> > of BlockCannotReturn recursion problem (in [1]), along with a battery of<br>
> > tests exploring termination of nested ensure and cascading errors behavior<br>
> > (Debugger tests are for info and a final version can wait until releasing<br>
> > Christoph's proposal in [2]).<br>
> > <br>
> > It's pretty much final, I hope...<br>
> > <br>
> > Any complaints about #terminate - please shout ;)<br>
> > <br>
> > [1] http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html<br>
> > [2]<br>
> > http://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-during-process-termination-tp5129800p5130110.html<br>
> > <br>
> > best,<br>
> <br>
> Here's the link:<br>
> http://forum.world.st/The-Inbox-Kernel-jar-1414-mcz-td5130198.html<br>
> <br>
> <br>
> <br>
> -----<br>
> ^[^ Jaromir<br>
> --<br>
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html<br>
> <br>
>