In article <[EMAIL PROTECTED]>, Navin Gupta
<[EMAIL PROTECTED]> wrote:
> In mailnews code there are several instances of opening a new
> nsInputFileStream and/or nsOutputFileStream and then just deleting the
> stream without closing it. One alternative would be to search for all
> such instances in our codebase and close them. Another, less tedious
> alternative would be to close the stream in it's destructor. Is it a
> good programming practice to close the stream in the destructor ?
I recently found a bug in nsBufferedStream, which is the base class of
nsBufferedOutputStream, in which nsBufferedStream::~nsBufferedStream()
was calling the virtual method nsBufferedStream::Close(), instead of the
overridden method nsBufferedOutputStream::Close(). When we open
nsFileOutputStreams, we typically wrap them with an
nsBufferedOutputStream. With this bug, any data written to the
nsBufferedOutputStream wouldn't get flushed upon destruction, because
the wrong Close() method would get called. The underlying
nsFileOutputStream would be closed, but no data would get written to the
file.
Now that this has been fixed, the correct Close() method will get called
upon destruction, so we don't absolutely require explicit calls to
Close(), but I would agree with others that it is good programming
practice to use explicit Close() calls, as it leads to fewer surprises.
- Patrick
--
// Patrick C. Beard
// Netscape Communications
