(Igor speaking with Clement) Another, tangent. I feel extremely wrong with given piece of code (however it works): [ ^ 2 ] ensure: [ ^ 5 ] my point, that you cannot return from same context twice, and what happens here is really weird. Or even more weird: [ ^ 2 ] ifCurtailed: [ ^ 5 ] or imagine more abstract case: someBlock ifCurtailed: [ ^ 5 ] The someBlock can belong to other context (like the caller context), and if evaluating it leads to non-local return, it must continue execution from the sender context of its home context. But alas, our ifCurtailed block thinks otherwise and intercepts that.. and does own non-local return to possibly alredy unwinded portion of stack.. I feel there's something extremely wrong with that :) We changed the #resume:through: method to catch that: unwindBlock ifCurtailed: [ self error: 'cannot resume execution due to curtailing' ] instead of: unwindBlock value i am, however don't really know what is the least surprising behavior for such situation. 2013/10/25 Stéphane Ducasse <stephane.ducasse@inria.fr>
If I remember correctly andreas wrote the tests. I always like them.
Stef
The author of the test is Andreas Raab, but I'm not sure who found it (excavating mailing list is hard work)
2013/10/25 Igor Stasenko <siguctua@gmail.com>
On 25 October 2013 00:26, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hard to debug this kind of code :( This is reproducible on Squeak wiht on:do:, so on:fork: bizareness apart, this is another flaw in exception handling, along with wrong handler for nested exception (testHandlerFromAction below), unless it's an avatar.
Still, I do not see how you get the errorSubscriptBound:... In Squeak that would mean that you sent #handleSignal: to a not isHandlerContext ContextPart... I never saw this, but if Eliot says so...
ExceptionTests>>testHandlerFromAction "A test ensuring that nested exceptions work as expected."
| result | result := [ [ [self error: 'trigger error'] on: ZeroDivide do: [ :ex | 'inner' ] ] on: Error do: [ :ex | 3 / 0 ] ] on: ZeroDivide do: [ :ex | 'outer' ]. self assert: 'outer' equals: result description: 'Incorrect handler'.
good find :)
https://pharo.fogbugz.com/f/cases/11996/Wrong-exception-handler-problem
2013/10/24 Igor Stasenko <siguctua@gmail.com>
ok, it seems i found how to reproduce the situation with following:
[ [ 1/0 ] ensure: [ nil foo ] ] on: Error fork: [ :ex | 1halt ]
you will get halt, and if you close the debugger , it will throw unwind error. (while instead it should throw DNU)
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.