Should a C++ program catch all exceptions and prevent exceptions from bubbling up past main()?

Question

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.

Answer 1

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...

Answer 2

The main reason for not letting exceptions escape from main is because otherwise you lose all possibility to control how the problem gets reported to your users.

For a program that is not intended to be used a long time or distributed widely, it can be acceptable that unexpected errors are reported in whatever way the OS decides to do it (for example, showing an in-your-face error dialog on Windows).

For programs that you sell, or that are provided to the general public by an organization that has a reputation to uphold, it is generally a better idea to report in a nice way that you encountered an unexpected problem and try to save as much of the user's data as possible. Not losing half a day's work of your user and not crashing unexpectedly, but shutting down semi-gracefully is generally much better for your business reputation than the alternative.

Answer 3

TL;DR: What does the specification say?

---

A technical detour...

When an exception is thrown and no handler is ready for it:

• it is implementation defined whether the stack is unwound or not
• std::terminate is called, which by default aborts
• depending on your environment setup, aborting may or may not leave a crash report behind

The latter can be useful for very infrequent bugs (because reproducing them is a time-wasting process).

---

Whether to catch all exceptions or not is, ultimately, a matter of specification:

• is it specified how to report user errors? (invalid value, ...)
• is it specified how to report functional errors? (missing target directory, ...)
• is it specified how to report technical errors? (assertion firing up, ...)

For any production program, this should be specified, and you should follow the specification (and maybe argue that it be changed).

For quickly thrown together programs to be used only by technical people (you, your teammates), either is fine. I recommend letting it crash and setup the environment to get a report or not depending on your needs.

Answer 4

An exception that you catch gives you the opportunity to print a nice error message or even try to recover from the error (possibly by just re-launching the application).

However, in C++ an exception doesn't hold information about the program state when it was thrown. If you catch it, all such state is forgotten, whereas if you let the program crash, the state is usually still there and can be read from the program dump, making it easier to debug.

So it's a trade-off.

Answer 5

The moment you know you have to abort, go ahead and call std::terminate already to curtail any further damage.

If you know you can wind down safely, do that instead. Remember that stack-unwinding is not guaranteed when an exception is never caught, so catch and rethrow.

If you can safely report/log the error better than the system will do it on its own, go ahead.
But be really sure not to inadvertently make matters worse while doing so.

It's often too late to save data when you detect an irrecoverable error, though it depends on the specific error.
Anyway, if your program is written for fast recovery, just killing it might be the best way to end it even if it's just a normal shutdown.

Answer 6

Crashing gracefully is a good thing most of the time -- but there are trade-offs. Sometimes it's a good thing to crash. I should mention that I'm mostly thinking about debugging in the very large. For a simple program -- although this might still be useful, it's nowhere near as helpful as it is with a very complex program (or several complex programs interacting).

You don't want to crash in public (although this is really unavoidable -- programs crash, and a truly mathematically verifiable non-crashing program is not what we're talking about here). Think of Bill Gates BSODing in the middle of a demo -- bad, right? Nonetheless, we can try to figure out why we crashed and not crash again in the same way.

I turned on a feature of Windows Error Reporting that creates local crash dumps on unhandled exceptions. It works wonders if you have the symbol files associated with your (crashing) build. Interestingly enough, because I set up this tool, I want to crash more -- because I learn from each crash. Then I can fix the bugs and crash less.

So for now, I want my programs to throw all the way to the top and crash. In the future, I might want to gracefully eat all my exceptions -- but not if I can make them work for me.

You can read more about Local Crash Dumps here if you're interested: Collecting User-Mode Dumps

Answer 7

Ultimately, if an exception bubbles up past main(), it is going to crash your application, and in my mind an app should never never crash. If it is ok to crash an app in one place, then why not anywhere? Why bother with exception handling at all? (Sarcasm, not really suggesting this...)

You might have a global try/catch that prints an elegant message telling the user that an unrecoverable error has occurred and that they need to email bob in IT about it or something similar, but crashing is completely unprofessional and unacceptable. Its trivial to prevent and you can inform a user about what just happened and how to fix things so it doesn't happen again.

Crashing is strictly amateur hour.