Hi Jaromir,
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.
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.
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?
Hm, do we need to implement both modi - (ii) and (iii) as described in [1] - in Context >> #unwindTo: as well? Something like #unwindTo:aggressive:?
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? :)
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? :-)
One more question about your #runUnwindUntilErrorOrReturnFrom: Are you maybe missing something like "cxt terminate" in the "No error was raised" case? Just wondering.
Best, Christoph
[1] http://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-duri...
--- Sent from Squeak Inbox Talk
On 2021-05-31T17:01:46-05:00, m@jaromir.net wrote:
Jaromir Matas wrote
Hi All, I've sent an updated version of #teminate integrating Christoph's solution of BlockCannotReturn recursion problem (in [1]), along with a battery of tests exploring termination of nested ensure and cascading errors behavior (Debugger tests are for info and a final version can wait until releasing Christoph's proposal in [2]).
It's pretty much final, I hope...
Any complaints about #terminate - please shout ;)
[1] http://forum.world.st/The-Inbox-Kernel-ct-1405-mcz-td5129706.html [2] http://forum.world.st/The-semantics-of-halfway-executed-unwind-contexts-duri...
best,
Here's the link: http://forum.world.st/The-Inbox-Kernel-jar-1414-mcz-td5130198.html
^[^ Jaromir
Sent from: http://forum.world.st/Squeak-Dev-f45488.html