2011/12/2 Bert Freudenberg <bert at freudenbergs.de>:
> 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


>> , 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:
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> <ContextPart-resume.st>
>
>
>
>