Re: What risk of undefined behavior if destructor must throw?
kanze wrote:
I'm not so sure. If you actually do hold the mutex, and for
some reason, the system cannot release it, your application is
hosed. About all you can do is get out as quickly as possible,
so that the backup can take over. (I can't actually think of
any case where this is possible, and Solaris doesn't provide an
error condition for it. But who knows.)
On Solaris it presumably isn't possible. The call will fail either if
the argument is not a mutex at all or your thread doesn't own it. Also
on Solaris it's possible to have a recursive mutex such that even if
you call unlock on it, it's not guarantee that you have unlocked it
because it uses reference-counting. (This can be useful for making RAII
lock objects copyable but I don't actually use them myself, my lock
objects are movable but not copyable).
If you don't hold the
mutex, but thought you did, then there is probably a serious
violation of your preconditions in the preceding code, which
also calls for getting out as quickly as possible.
That's what asserts are for. In release mode I would not want an
application to terminate for some reason that may not even be fatal. I
could lose all my work. Or if it's a server, business could be lost.
Unless you've designed it so that you may or may not hold the
mutex at this point, and the failure is because you aren't the
owner. I'm sceptical of such designs, but not to the point
where I'd say that they are never appropriate.
My own are not designed this way but my own mutex lock object does not
work this way. My lock object can lose its ownership but it has a
boolean flag for such a condition.
What books? If a book recommends a catch(...) without a throw
in the catch block, I'd throw it out.
Not sure I agree with you there. Of course that doesn't apply in my own
code where all the exceptions derive from std::exception or from
CORBA::Exception. Personally I have never really seen the need for
typed exceptions. A single type would suffice and would suit embedded
systems. On those occasions where you handle exceptions differently,
you catch, check the contents and handle accordingly, rethrowing if
appropriate.
There are cases where catch(...) is appropriate. The rule
should be more along the lines that every catch(...) must have a
code block which ends with a parameter-less throw (or calls some
function which does a parameter-less throw).
Yes, ideally we'd at least log the exception even if we're not going to
act on it. If I have a multi-threaded system where some worker thread
is shutting down and an exception is thrown that I can't recover from,
it doesn't mean that the rest of my code is unstable.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]