Navin Gupta 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 ?
It's better to clean up from the dtor than to leak a file descriptor,
certainly!
It's a bad idea to do things from a destructor that assume other objects
are resources are still alive, when there is no strong reference held by
the object being destroyed. Such hacks may happen to work, given an
order of destruction in place due to tradition -- but as soon as someone
holds a strong ref to the object in question a bit longer, the order can
change in ways that violate the assumptions made by the destructor.
Can you show some code diffs? That's the only way to be sure, but it
sounds ok to clean up stream private state (especially open file
descriptors) from a dtor, iff close hasn't been called (if close *has*
been called, then state should be cleared or otherwise reset so the dtor
can know not to double-free/release/close).
/be
