[gclist] What does a garbage collector do about

[Boehm, Hans]

I agree with this approach, so long as you apply it only to those cases in which it is feasible to synchronously close the file without doing major damage to the client code.  That isn't always the case.  It fails if file descriptors are deeply embedded in a complex data structure.  I'd much pefer to have the occasional read-only file closed late than to have the programmer try to implement some (probably buggy) reference-count scheme on top of the existing system-supplied garbage collector solely to deal with this case.

Hans

-----Original Message-----
From: Fergus Henderson
...
We should also make use of tools to *detect* such problems.  We should
not expect perfection, but our development model, development processes
and development tools should do the best they can to encourage it.

So, in debugging mode, finalizers for open output files should report
the problem (failure to explicitly close the open output file)
in a hard-to-ignore way, e.g. aborting the application.

In production mode, they should log such errors and then do their
best to continue (i.e. close the file).   Failure to explicitly close
the file should be treated as a programming error (and logged),
regardless of whether the close operation encounters an I/O error or
not. 

Tools should be configured so that they default to debugging mode,
so that problems are reported rather than being smoothed over.