Risking the exception anti-pattern.. with some modifications

Question

Lets say that I have a library which runs 24x7 on certain machines. Even if the code is rock solid, a hardware fault can sooner or later trigger an exception. I would like to have some sort of failsafe in position for events like this. One approach would be to write wrapper functions that encapsulate each api a:

returnCode=DEFAULT;
try
{
  returnCode=libraryAPI1();
 }
catch(...)
{
 returnCode=BAD;
}
return returnCode;

The caller of the library then restarts the whole thread, reinitializes the module if the returnCode is bad.

Things CAN go horribly wrong. E.g.

if the try block(or libraryAPI1()) had:

 func1();
 char *x=malloc(1000);
 func2();

if func2() throws an exception, x will never be freed. On a similar vein, file corruption is a possible outcome.

Could you please tell me what other things can possibly go wrong in this scenario?

Answer 1

This code:

func1();
char *x=malloc(1000);
func2();

Is not C++ code. This is what people refer to as C with classes. It is a style of program that looks like C++ but does not match up to how C++ is used in real life. The reason is; good exception safe C++ code practically never requires the use of pointer (directly) in code as pointers are always contained inside a class specifically designed to manage their lifespan in an exception safe manor (Usually smart pointers or containers).

The C++ equivalent of that code is:

func1();
std::vector<char> x(1000);
func2();