(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.