Re: throwing dtors...
"Chris M. Thomasson" <no@spam.invalid> wrote in
news:X5_Ek.12946$ex3.3200@newsfe02.iad:
"anon" <anon@no.invalid> wrote in message
news:gc1n78$kks$1@news01.versatel.de...
Chris M. Thomasson wrote:
Is it every appropriate to throw in a dtor? I am thinking about a
simple example of a wrapper around a POSIX file...
Take a look here:
http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.13
Okay; I will give it a look.
[...]
How would you handle it in C?
[...]
What can you do when fclose fails?
Well, it depends on the error:
http://www.opengroup.org/onlinepubs/007908775/xsh/fclose.html
For instance, fclose can get interrupted by a signal. In this case,
you need to reissue the operation; e.g:
______________________________________________________________
struct file {
FILE* handle;
};
int file_close(
struct file* const this
) {
int status;
do {
status = fclose(this->handle);
} while (status == EOF && errno == EINTR);
return status;
}
______________________________________________________________
Or, what if it returns `EAGAIN', well, this certainly needs to be
handled. However, it would be better to let the application to handle
this, not do it implicitly within the `file_close()' function. There
are many ways to handle this. That's not the problem. The problem is
when a retarded program does not handle it! IHO, any program that does
not explicitly handle errors from `fclose()' is severely broken and
VERY dangerous. Let me give you a example... Imagine a C++ wrapper
around a C FILE... Fine. Imagine the dtor looks like this:
class file {
FILE* m_handle;
public:
~file() throw() {
fclose(m_handle);
}
};
Fine... Now, a user needs to copy a file to a disk, and destroy the
original. Okay. It creates two file objects (e.g., src and dest:)
{
file src(...);
file dest(...);
// Then it performs the copy operation:
[copy src to dest]
}
Now the code-block goes out of scope, and no exceptions were thrown
during the copy process, HOWEVER, the call to `fclose()' in the dest
object failed!!!! Well, the user thinks everything is fine because the
completely retarded ignorant moron file object did not report the
fuc%ing error! So the user operates in ignorance and happily destroys
the original file thinking that the file was COMPLETELY copied onto
the disk! WRONG! The file was partially copied because `fclose()'
failed to do its thing and properly flush the buffers, or whatever...
Now, the missing file data is LOST __forever__! OUCH!!!
This is why its ESSENTIAL to report and handle errors from
`fclose()'... If `fclose()' fails, you can't be so sure that the file
is 100% coherent...
Any thoughts?
Yep, you're not using exceptions appropriately. What should be
happening is your loop around fclose should be in the destructor itself.
By throwing an exception out of the destructor you are effectively
saying that the object was unable to be destroyed. Now you're in for a
whole world of hurt. How can you possibly recover from that? The
object is already on its way out of scope, and now you can't destroy it.
You can't abort the object going out of scope. Really, if the caller
really was ready to handle errors from fclose, then they should be using
whatever method of the file class that just does fclose before allowing
the object to fall out of scope.
Additionally a whole different world of hurt happens is you have an
array of these things. Let's assume an array of 10 of them. Also let's
assume that object #7 throws an exception during construction. So the
program dutifully destroys all of the previous objects that it had
previously fully constructed. And object #3 throws an exception during
its destructor. Now you have 2 active exceptions running around.
That's a short trip to a terminated program. You can't catch it. This
is probably the best example of why allowing exceptions to propogate out
of destructors is a Bad Thing.