C++ – Should Programs Catch All Exceptions and Prevent Bubbling Past Main

cexceptions

I was once advised that a C++ program should ultimately catch all exceptions. The reasoning given at the time was essentially that programs which allow exceptions to bubble up outside of main() enter a weird zombie state. I was told this several years ago and in retrospect I believe the observed phenomenon was due to lengthy generation of exceptionally large core dumps from the project in question.

At the time this seemed bizarre but convincing. It was totally nonsensical that C++ should "punish" programmers for not catching all exceptions but the evidence before me did seem to back this up. For the project in question, programs that threw uncaught exceptions did seem to enter a weird zombie state — or as I suspect the cause was now, a process in the midst of an unwanted core dump is unusually hard to stop.

(For anyone wondering why this wasn't more obvious at the time: The project generated a large amount of output in multiple files from multiple processes which effectively obscured any sort of aborted (core dumped) message and in this particular case, post-mortem examination of core dumps wasn't an important debugging technique so core dumps weren't given much thought. Issues with a program usually didn't depend on state accumulated from many events over time by a long lived program but rather the initial inputs to a short lived program (<1 hour) so it was more practical to just rerun a program with the same inputs from a debug build or in a debugger to get more info.)

Currently, I'm unsure of whether there is any major advantage or disadvantage of catching exceptions solely for the purpose of preventing exceptions from leaving main().

The small advantage I can think of for allowing exceptions to bubble up past main() is that it causes the result of std::exception::what() to be printed to the terminal (at least with gcc compiled programs on Linux). On the other hand, this is trivial to achieve by instead catching all exceptions derived from std::exception and printing the result of std::exception::what() and if it's desirable to print a message from an exception that doesn't derive from std::exception then it must be caught before leaving main() in order to print the message.

The modest disadvantage I can think of for allowing exceptions to bubble up past main() is that unwanted core dumps may be generated. For a process using a large amount of memory this can be quite a nuisance and controlling core dumping behavior from a program requires OS-specific function calls. On the other hand, if a core dump and exit is desired then this could instead be achieved at any time by calling std::abort() and an exit without core dump can be achieved at any time by calling std::exit().

Anecdotally, I don't think I've ever seen the default what(): ... message printed by a widely distributed program upon crashing.

What, if any, are the strong arguments for or against allowing C++ exceptions to bubble up past main()?

Edit: There are a lot of general exception handling questions on this site. My question is specifically about C++ exceptions that cannot be handled and have made it all the way to main() — maybe an error message can be printed but it's an immediately show stopping error.

Best Answer

One problem with letting exceptions go past main is that the program will end with a call to std::terminate which default behavior is to call std::abort. It is only implementation defined if stack unwinding is done before calling terminate so your program can end without calling a single destructor! If you have some resource that really needed to be restored by a destructor call, you're in a pickle...