0326a20b
From: bouncer@dev.null
Edward Rosten wrote:
> On May 28, 3:01 am, Wil Evers wrote:
>
>> So we're left with a choice. We can use some other error reporting
>> mechanism, but that would mean we are back to relying on our caller
>> to to discover the error and act accordingly. Alternatively, we
>> can try to restrain ourselves and only use destructors for things
>> that cannot reasonbly fail. That is my preference.
>
> I don't see that as an alternative, unless I've misunderstood. If
> you don't put close() in the destructor, you rely on the caller of
> the class both remembering to destroy it properly and checking for
> errors when it has done so.
>
> I think the problem is that sometimes failure can lead to cascading
> errors and how to deal with that is not necessarily obvious.
> Exceptions mostly make the usual, simple case trivial.
>
> There is, of course the other problem is that not close()ing a file
> in a destructor is likely to lead to far more errors than double
> throws caused by close() failing.
As I said elsewhere in this thread, it is possible to equip the
class holding the file descriptor with an explicit close() member
function that will throw an exception if the close() system call
reports an I/O error. The class's destructor would check to see if
the descriptor is still open, and close it if it is, without checking
for any I/O errors. That would prevent a descriptor leak, as well as
a double fault if the destructor is invoked when unwinding the stack.
Obviously, this essentially just redefines the problem by simply
ignoring I/O errors when the close() system call is invoked from the
destructor, and it relies on users interested in these errors to do
the right thing. However, given the way the close() system call is
defined, this is probably the best we can do.
- Wil
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
