0326a20b
From: gelists@gmail.com
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.
Seems to me that the choice here depends on the requirements.
If an error during close() (whatever this means) needs "higher-up"
actions, close() should throw an exception in case of error that can be
caught "higher up" -- and therefore close() needs to be called
explicitly before the dtor. The dtor probably should contain an
assertion that close() has been called.
In many cases, however, this is not necessary and close() can be called
in the dtor. If it fails, there is either something that can be tried
(like wait and retry), which then can be tried in the dtor (or in
close() itself), or there isn't, in which case there usually is no need
for further action anyway.
Gerhard
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
