finalisation
Lex Spoon
lex at cc.gatech.edu
Fri Jan 30 00:05:57 UTC 2004
Jesse Welton <jwelton at pacific.mps.ohio-state.edu> wrote:
> Date: Wed, 28 Jan 2004 14:22:28 -0500 (EST)
> From: Jesse Welton <jwelton at pacific.mps.ohio-state.edu>
> Subject: Re: finalisation
> To: squeak-dev at lists.squeakfoundation.org
> reply-to: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
>
> Andreas Raab wrote:
> >
> > > Does this not catch all the possibilities ?
> >
> > No, of course not. That's why I find the style of putting the resource
> > creation inside the ensured block so terribly misleading. It puts you under
> > the impression that you caught all the possibilities, where it is easy to
> > see from an example like
> >
> > [file := (FileStream newFileNamed: 'foo.bar') halt.
> > ] ensure:[file close].
> >
> > that you do not catch anything that happens on the right hand side of the
> > assignment. IOW, execute the above and close the resulting debugger - it
> > will end up with a DNU for file close which illustrates that - although the
> > file has been created - it is not being cleaned up after encountering the
> > halt.
>
> Andreas, you correctly point out that this failure mode cannot be
> caught and handled. If I understood Craig, the failure mode he was
> referring to would be simulated by
>
> (file := (FileStream newFileNamed: 'foo.bar')) halt.
> [ file doStuff ] ensure: [ file close ].
>
> Here, the failure can be caught by moving the file creation into the
> block. You argue that this is statistically unlikely, but as Craig
> and Richard point out, this kind of thing can and does happen
> occasionally.
Why would this failure mode happen? The only time I can see is if you
are sending #terminate to your processes from code, and you should not
do that.
If you are talking about people pressing alt-., then I think you just
have to live with an occasional stray resource. That seems perfectly
reasonable; run a garbage collection if need be.
If you are doing #terminate, then you cannot win. Even if you do this
version:
[ file := "open a file" ]
ensure: [ "close the file if non-nil" ]
then you *still* do not catch it if the file gets opened, and the
file-open method is returning, but the interrupt happens before the
return statement completes.
-Lex
More information about the Squeak-dev
mailing list
|