Hi Tim,

> > That's why I'm saying putting the resource creation inside the ensured
> > block doesn't give you anything, and that's why you don't need explicit
> > guards nor stub methods in UndefinedObject. You simply can't handle
> > failures that arise from resource creation contained inside some
> > ensured block that should cover the release of that resource.
> Not quite completely true,

Why not?

> though it would require a change in the resource allocation
> behaviour to be clean.
> a) one could simply do the ugly thing and make UndefinedObject respond
> to the resource release message (yuck)
> b) one could return an instance of FailedResourceAllocationDoohickey
> rather than nil when the file open fails and provide it with protocol
> to do various useful things. Like maybe retry under some situations,
> release 'cleanly' and so on.

Wouldn't matter one bit. (Am I really explaining myself so poorly?) All I'm
saying is that there's no reason to put the resource creation into the
ensured block, as, no matter what you do, if the resource allocation fails
(and returns anything but that allocated resource) you don't need to handle
it (the resource hasn't been allocated so why free it?). Given that this is
the case, it seems that for reasons of clarity alone the ensured block can
(and should) only cover the portion of code where you can rightfully assume
that you do in fact have a valid resource. For example, even with your
FailedResourceAllocationDoohickey I would claim that it's simpler and more
easy to understand if you have code that says, e.g.,

    file := self openFile:'foo.bar'.
    file == FailedResourceAllocationDoohickey
        ifTrue:[^self error: 'could not open file']. "or whatever"
    [self doSomethingWith: file] ensure:[file close].

Cheers,
  - Andreas