C ++: Should I catch all exceptions or let the program crash?

Question

I have a Windows service written in (Visual) C ++ with a very detailed logging function that often helped me find the cause of errors that clients sometimes encounter. Basically, I check every return value and log what happens and where the errors come from.

Ideally, I would like to have the same granularity of visibility in exceptions (for example, an out-of-range array, division by zero, etc.). In other words: I want to know exactly where the exception comes from. For reasons of readability and practicality, I don’t want to wrap all several lines of code in separate try / catch blocks.

What I have today is one common catch that catches everything and logs an error before closing the program. This is good from the point of view of the user - a clean shutdown instead of crashing the application - but bad for me, because I get a general message from the exception (for example, "an array is out of range"), but I have no idea where it comes from.

Wouldn't it be better to remove catch-all and let the program crash instead? I could direct the client to let Windows dump the application (as described here ). With the dump file, WinDbg will precisely point to the position in the code where the exception was thrown.

Answer 1

You can register a custom, vector exception handler by calling AddVectoredExceptionHandler .

This will be called whenever an exception is thrown, and in it you can create a stack trace that you can then save for logging.

Writing code for this is not completely trivial, but not a rocket.

I never personally did this in C ++, but I would be surprised if there were no ready-made libraries that make it available somewhere, if you do not have the time or desire to do it yourself.

Answer 2

You can throw exceptions with a description of where the error occurred, and why:

throw std::string("could not open this file"); 

If you do not want to write different descriptions for each possible error, you can use the standard __FILE__ and __LINE __ macros:

 #define _MyError std::string("error in " __FILE__ + std::to_string(__LINE__)) // ... throw _MyError; 

If the original file name and the error line are not enough, and you need additional information, such as a stack trace or memory values, your program can generate a debugging report. Google Breakpad is a C ++ library that allows you to do this in a portable way. The wxDebugReport class from the wxWidgets library is an alternative. On Windows, debugging reports can include a minidump file that can be loaded into Visual Studio and allows you to analyze the error in the same way as debugging.

Answer 3

Wouldn't it be better to remove the trap and let the program crash instead?

You can catch everything and

• Write a (more personal) message about the fatal error that occurred, causing the application to close. Do not let the program continue: you do not know what happened, where. Continued may corrupt user data, track errors, etc.
• Let the user contact you with the specifics of what they did and what happened.
• Inform the user of the inclusion of the log file generated by your application.

If you do not do something like this, then you can just remove catch-all.

For reasons of readability and practicality, I don’t want to wrap every few lines of code in separate try / catch blocks.

And yet, if you want your program to recover, this is exactly what you need to do. What you can do is

• Let the user know what happened, maybe something is wrong with the input that could cause it. Do not make it technical.
• Save any data that the user has entered so that their work is not completely lost.
• You know at what stage the failure occurred. Undo this step, i.e. discard objects / data and return to the point before the exception.
• Restore the data entered by the user from the second point so that they do not repeat the actions again and again.

The fact is that your program may return to an acceptable state.