How to end a C ++ program after an error?

Question

I am refactoring old code, and one of the things I would like to consider is a way to handle errors. I know well about exceptions and how they work, but I'm not entirely sure that they are the best solution for the situations I'm trying to handle.

In this code, if something is not checked, there really is no reason or advantage for unwinding the stack. Were made. It makes no sense to try to save the ship, because it is non-interactive code that works in parallel through the Sun Grid Engine. User cannot intervene. Moreover, these verification errors do not represent exceptional circumstances. They are expected.

So, how do I better handle this? One thing I'm not sure what I want is the exit point in each method of the class, which can fail. It seems unattainable. Am I mistaken? Is it acceptable practice to just call exit() or abort() at the point of failure in such codes? Or should I throw an exception by referring to some generalized statement in main? What is the advantage?

Answer 1

Throwing exceptions that will be caught in the main and then thrown means that your RAII resource objects will be cleared. On most systems, this is not required for a large number of resource types. The OS will clear memory, file descriptors, etc. (Although I used a system in which the lack of free memory meant that it remained allocated until the system rebooted, so a leak on the program output was not a good idea.)

But there are other types of resources that you might want to release clean, such as connecting to a network or database, or a mechanical device that you control, and you need to safely disconnect it. If an application uses a lot of these things, you might prefer an exception to restore the original stack and exit.

Thus, the appropriate exit method is application dependent. If the application knows this safely, then calling _Exit (), abort (), exit (), or quickexit () can be perfectly reasonable. (The library code should not call them, because obviously the library does not know whether it will be safe for every application that will ever use the library.) If there is any critical cleanup that must be performed before the application exits, but you know that it is limited, the application can register this cleanup code through atexit () or at_quick_exit ().

So, basically decide what you need to clean, document, put in it and try to make sure that it is tested.

Answer 2

It is permissible to terminate the program if it cannot handle the error gracefully. There are a few things you can do:

• Call abort() if you need a kernel dump.
• Call exit() if you want to allow those procedures registered with atexit() to run (this will most likely cause destructors for C ++ global objects).
• Call _exit() to terminate the process immediately.

There is nothing wrong with using these functions if you understand what you are doing, know your other options, and willingly choose this path. After all, why do these functions exist. Therefore, if you do not think it makes sense to try to cope with the error or do something else when this happens, continue. What I'm likely to do is try to write an informational message (say to syslog) and call _exit . If the log fails, call abort to get the kernel upon completion.

Answer 3

I would suggest calling a global function

 void stopProgram() { exit(1); } 

Later you can change his behavior, so it can be restrained.

Answer 4

As you indicated, having exit or abort thrown throughout your code is not supported. In addition, in the future there may be a mechanism that can allow you to recover from an error or handle the error in a more elegant manner than just exiting, and if you had already programmed this functionality, then it would be very difficult to cancel it.

Throwing an exception caught in main() is your best option at this stage, which will also give you flexibility in the future if you run the code in another script that will allow you to recover errors or handle them differently. In addition, throwing exclusion can help if you decide to add additional debugging support, etc., since this will give you the opportunity to implement logging functions and record the state of the program from isolated and supported points in the software before you decide that the program went out.