#ensure: What would you expect?

Dear All,

given the following class:

Object subclass: #Foo
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'Foo'!
a
        self b: [^ 1].! !

b: aBlock

        [self c: aBlock] ensure: [^ 2].

c: aBlock

        aBlock value.
        ^ 3

And you would do

Foo new a

what would you expect?

I am very curious.
Please, first guess, then execute.

Best
        -Tobias

On 02.12.2011, at 15:18, Tobias Pape wrote:


I expected two possible outcomes (because putting a return in the ensure block is unusual).

But what it actually answers is surprising.

- Bert -

There is only one possibly correct answer which is raising
BlockCannotReturn, because we're trying to return while we're in the
midst of returning already, so there is no place to return to. That
answer is implemented by the attached change set.

BTW, the code duplication between ContextPart>>restart
ContextPart>>resume:, ContextPart>>unwindTo:, and Process>>terminate
bothers me greatly. The change set only fixes one of these locations
(the one triggered by your problem statement) but having such critical
code duplicated all over the places can't be good. Any takers?

Cheers,
   - Andreas

On 12/2/2011 15:18, Tobias Pape wrote:

On 02.12.2011, at 17:17, Andreas Raab wrote:

> There is only one possibly correct answer which is raising BlockCannotReturn

+1

- Bert -

2011/12/2 Bert Freudenberg <[hidden email]>:
> On 02.12.2011, at 17:17, Andreas Raab wrote:
>
>> There is only one possibly correct answer which is raising BlockCannotReturn
>
> +1
>
> - Bert -
>

I didn't and don't want to look into the implementation...
My own expectations for (firstBlock ensure: secondBlock) are:
1) firstBlock is executed first and secondBlock is executed just after
2) secondBlock gets executed even if firstBlock has a non local return
(this happens during stack unwinding)
3) secondBlock is executed in the context sending  #ensure:
4) the result of (firstBlock ensure: secondBlock) is that of (firstBlock value)

If secondBlock has a non local return, It violates rule 4), is this acceptable?

If answer is no, then don't bother, this means we should never honour
a non local return outside the context executing #ensure: from within
the ensure block (or any other unwind block).
This would be my favourite answer but maybe there are other subtle
implications in exception handlers... (can they contain a non local
return ?).

If answer is yes, then we have to handle the conflict when both blocks
have a non local return, which is the case you submitted.
Should we give priority to firstBlock or secondBlock or raise an
exception ? The later seems wise... Maybe a bit nasty to explain.
Though, if we remove rule 4), since we execute secondBlock during the
unwind we can as well preempt non local return and ^2 in the senders
of #b:.
In which case execution will continue in #a and answer a Foo, which
has a certain logic.
I did not browse nor execute anything, but read the answer other
obtained, so consider that I'm a cheater.

Nicolas

--
best,