> Doesn't this assume that the only thing that happens
> inside the resource allocation method is in fact the
> resource allocation.
>
> For instance, when opening a file stream, the file is also
> registered for finalization. If this fails (for whatever reason),
> the resource has been allocated, but will possibly cause
> a walkback, and closing the walkback will not release the
> resource.
>
> Just a thought...

You are precisely right. But if you look at, say:

    [file := FileStream newOnlyFileNamed: 'foo.bar'.
    ] ensure:[file close].

then, if the registrations fails inside #readOnlyFileNamed: you wouldn't be
able to release the resource by doing "file close" simply because the
variable "file" has not been assigned yet. In other words, at the point
where your registration fails and you get your walkbalk the value of the
variable "file" is nil - and therefore the operation "file close" can't do
anything either.

You can try it for yourself if you wish - just evaluate something like

    [file := (FileStream newFileNamed: 'foo.bar') halt.
    ] ensure:[file close].

which will simulate a "right hand side error" (e.g., any error inside the
resource creation method) and look at the "file" variable inside the
debugger. As you will see it's nil (since the RHS expression hasn't been
completed yet) and closing the debugger will get you a DNU for nil>>close.
And yet, the resource has been allocated, but the above pattern (e.g.,
putting resource creation inside the ensured block) is simply unable to
handle this kind of problem.

That's why I keep saying that there's really no point in putting the
resource creation inside the ensured block. And yes, I must be explaining
myself really, really poorly here ;-)

Cheers,
  - Andreas