Re: throwing dtors...
"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?