(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 <[email protected]> > 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 <[email protected]> > >> >> >> >> On 25 October 2013 00:26, Nicolas Cellier < >> [email protected]> 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 <[email protected]> >>> >>>> >>>> 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. >> > > >
