andreas.raab at gmx.de
Mon Jan 26 09:38:33 UTC 2004
You're still missing the major part of my argument. What I'm trying to say
here is that there's a fundamental uncertainty principle when you put the
"creation part" for some resource inside a block that should ensure the
release of said resource. Let's look at this more closely. You may have
something that says:
[resource := <some resource creating expression>
"... more stuff ..."
] ensure:[resource release "close, whatever"].
If, for whatever reason, the "resource creating expression" fails to
complete (raising an exception, just terminating whatever) there is no way
by which you can release the resource in the above code simply because the
"resource" variable hasn't been assigned yet. Meaning that it is basically
useless to put the creation part inside the ensured block. The only thing
you gain by doing this is that you cover the microscopically small chance
that the computation gets terminated right after assigning to the resource
variable but before entering the ensured block. One way to make it "safer"
would be to use a pattern where you say (going back to the file example):
file := FileStream new.
[file openFileNamed: 'foo.bar'.
"... do stuff ..."
] ensure:[file close].
since here you'd have in fact a valid "file" variable when you open the
file, but then again, you could not ensure the actual creation (FileStream
new) as the same uncertainty principle applies (e.g., if #new fails you
wouldn't have a valid file variable and therefore your release operation
cannot handle the failure).
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.
----- Original Message -----
From: "Craig Latta" <craig at netjam.org>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, January 23, 2004 6:31 PM
Subject: re: finalisation
> > ...if you cannot really handle the failure...
> In this case, as I mentioned elsewhere in this thread, the solution is
> to raise an exception in the file-creation behavior, instead of
> answering nil. Then one can handle the failure, quite literally (with an
> exception handler).
> > ...and you agreed that it wouldn't prevent a dangling resource
> > pointer...
> The part of my point you're leaving out is that my suggestion was for
> better coverage, although not complete (given that the file-creation
> behavior is broken).
> > ...what's gained by putting the creation inside the ensured block
> > except from having to add explicit guards for the cleanup code?
> What's gained is the occlusion of a failure mode which I have seen and
> which is not pleasant. And, as I have also already mentioned in this
> thread, those guards aren't necessary if one is willing to define a
> no-op UndefinedObject>>close.
> Craig Latta
> improvisational musical informaticist
> craig at netjam.org
> [|] Proceed for Truth!
More information about the Squeak-dev