On 29 oct. 2013, at 13:22, Clément Bera <[email protected]> wrote:
> (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 ] Debug it -> Into -> Over -> Over (does nothing) -> Over (again) ==> Freeze :) > > 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. >> > >
