Subject: Re: [boost] [C++11] If you have an old class with a throwing destructor...
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-09-16 17:15:19
On 16 Sep 2013 at 16:47, Eric Niebler wrote:
> Sure. And then? Don't say, "Quietly swallow the exception." Something
> Very Bad has happened. Ignoring it inevitably leads to Something Worse
> (like data corruption, security vulnerabilities, etc). The only sensible
> option is to terminate, which is why the language semantics are what
> they are. The OP's suggestion to litter destructors with try/catch is
> misguided. That's no way to build reliable systems.
I agree that if your program has entered undefined state, you need to
fatal exit.
Fatal exit != immediate std::terminate() though. There's plenty of
very useful things you can do before you die such as flush buffers,
kick out memory maps, dump a trace file etc.
Regarding the other comments about "keeping destructors simple enough
they never throw", sure I agree that if a C++ expert designed and
wrote all the code then throws from destructors are likely to not
occur. However in the real world destructors call third party code
and who knows what they could throw. The truth is that in real world
code written by non experts you have to assume that every single line
of C++ can *always* throw, unless it is a function marked noexcept or
it is a function marked extern "C" (and even then some compilers
allow C++ exceptions to traverse C code).
I therefore return to my original statement that wrapping destructors
in try...catch is both useful and wise. Note I did not state that
fatal exit isn't the wisest choice if a destructor does throw. Unless
you're bothering to universally write restartable destructors, and
far more importantly to bear the maintenance burden of doing so and
training in staff to do so, fatal exit on destructor throw is the
best course of action.
Niall
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/