I'd think the ensure blocks haven't run yet because the return: messages 
sent to the exceptions haven't finished, so exception handling hasn't 
had a chance to unwind the stack yet.  If I understand things right, 
what you are seeing is the expected behavior --- because e.g. nobody 
knows whether an exception handler might fix something (or retry, or...) 
and resume past the exception instead of aborting the block.

On 9/5/16 12:30 , Chris Muller wrote:
> Hi all, I have some in this code in which I try to read a file and, if
> it fails, try to read it in a different way.
>
> But the order of processing ensure: blocks vs. error-handler blocks is
> not what I expected.  I expected the ensure: block of the inner
> handler to run before the outer handler.
>
> Here's a simple workspace to demonstrate. The temp var "open"
> represents the status of a FileStream.
>
> |open| open:=nil.
> World findATranscript: nil  Transcript clear.
> [ [ [ "try method1"  open:=true.  Error signal] ensure: [ open:=false] ]
>     on: Error
>     do:
>         [ : innerErr |   "try method2, but file still open!"
>         Transcript cr; show: 'innerErr handler, open is ', open asString.
>         innerErr return:
>             ([ open:=true.
>             Error signal ] ensure: [ open:=false ]) ] ]
>
>     on: Error
>     do: [ : outerErr | Transcript cr; show: 'outerErr handler, open is
> ', open asString ].
> Transcript cr; show: 'Done.  open is ', open asString.
>
> It seems none of the ensure blocks are processed until after ALL the
> error-handler blocks.  So if a #fileNamed:do: deep deep in the stack
> encounters an Error, the file is still open in the upper-level
> handlers, with no good way to close it..
>
>