Richard A. O'Keefe
Thu, 10 Apr 1997 12:41:19 +1000 (EST)
Why is it that "closing a file" is such a common example of finalisers?
If you assume a perfect world, so that the mere act of asking for something
to be written is a guarantee that it will be, then closing by finalising
makes sense. But in the real world, you really want something like
out_ok = open ok and then write ok and then write ok and then close ok
What happens if you are relying on close-by-finaliser and the attempt to
close the file fails? Presumably the entire chunk of the program that
knew about the file and so could have attempted some kind of recovery
(perhaps by writing to a different file) has disappeared.
The same thing applies to network connections: if you send a Disconnect
request, and the other end says "eh what? I've never heard of you" that
casts doubt on the delivery of earlier messages (or the survival of
their effects). Surely you don't want the part of the program that
knew there _was_ a network connection to have disappeared when the
exception "disconnect failed" is raised?
Another common example is closing windows, and there again, if the window
system is an integral part of the system running the program, I suppose
it's ok, but if you're using the X Window System over a net it is
conceivable that the program might drop its last reference to a window,
the finaliser might ask for the window to be closed, and the network
might drop that request, and the program would proceed with the window
still on the screen.
The underlying assumption, in other words, appears to be that finalisers
never fail, or that if they do, the program couldn't have done anything
about it anyway.
Releasing resources that are purely internal to the program is another
matter, of course.
What have I misunderstood?