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/