Re: What risk of undefined behavior if destructor must throw?
From my previous post.
What "bad" things could happen by a throwing destructor in this example?
class MutexGuard {
HANDLE handle;
public:
MutexGuard(HANDLE h) : handle(h) {
if (!WIN32_API::AcquireMutex(handle)) // Not a real WIN32 API
function -- just pretend.
throw Win32Error(GetLastError());
// Ok. 'handle' is valid, I own the mutex.
} // ctor
~MutexGuard() {
if (WIN32_API::ReleaseMutex(handle))
return;
unsigned long error = WIN32_API::GetLastError();
Log << "Oh no!! Its almost inconcievable, but ::ReleaseMutex
failed with error code: " << error << endl;
throw Win32Error(error); // Hope for the best.
} // dtor
}; // MutexGuard
In this example, there are three choices if ReleaseMutex fails. Terminate
right now, ignore the error, or throw something.
Terminate seems drastic, but preferable to ignoring the error. Ignoring
could cause the program to hang or produce incorrect results -- a fate
_worse_ than death. Throwing seems preferable, but only if I understand the
consequences of this "bad" behavior.
Herb Sutter and Andrei Alexandrescu, in "C++ Coding Standards" give the
following consequences:
1) [snip] You can't reliably instantiate automatic Nefarious objects in
a scope if that scope might be exited through an exception. If that
happened, Nefarious's destructor (automatically invoked) might attempt to
throw an exception as well which would result in sudden death of your entire
program via std::terminate.
Okay, so if the stack is unwinding, attempting to throw is the same as
"terminate right now", Reducing "throw" to terminate, still better than
"ignore".
2) Classes with Nefarious members or bases are also hard to use safely:
Nefarious' poor behavior extends to any class of which Nefarious is a member
or a base class.
Okay, the behavior that I think is "right" is consistently applied. Not a
bad thing (to me).
3) You can't reliably create global or static Nefarious objects either:
Any exception its destructor might throw can't be caught.
Okay too. The program terminates before it even gets going. Better than
attempting to run while intoxicated.
4) You can't reliably create arrays of Nefarious: In short, the
behavior of [partially constructed] arrays is undefined in the presence of
destructors that throw.
Is it? If the constructor of the fourth element of a ten-element array
throws, then the previously constructed elements are destroyed. If one of
those destructors also throws, then std::terminate is called. No? Again,
calling std::terminate sounds better than ignoring the error.
5) You can't use Nefarious objects in standard containers: [snip] the
standard library forbids all destructors used with it from throwing.
Or they'll do what? This needs to be defined. STL containers should define
what they do if clients' destructors fail, rather than righteously avoiding
the problem. Granted. they may specify that std::terminate() is called.
Hopefully, they only leak memory or something innocuous, but avoid
formatting my harddrive.
[6) swap() won't work]
I think swap() typically works, but the temporary object destruction fails.
I.e. template<T> swap() is nothrow only if ~T is nothrow.
I'm not sure what the consequences of this are.
In conclusion, ignoring an error that you don't understand seems worse than
terminating immediately.
Throwing an exception from a destructor seems preferable to terminating
immediately, unless unwinding (bang!).
My claim is: "If you catch() an exception you don't understand, always
rethrow, even in a destructor."
With RAII, should we avoid catch(...), except to write an epitaph before
terminating?
Herb Sutter implies that we can prevent bad things from happening, that
programming should be "safe".
I don't think it really is safe. All hardware fails eventually. What do we
do then?
Be reasonably cautious, I hope.
terry
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]