Among C++ developers there often appears to be a misconception about what it means to deal with code that can throw exceptions. The misconception is that the possibility of exceptions means one has to `try` and `catch` often and almost everywhere. I will try to explain why I think that is wrong and where I think `try`/`catch` is appropriate and where not.

Exception type multitude

One of the biggest problems with Exceptions is that you sometimes don’t know for sure which kind of errors might occur during the execution of a piece of code and what exceptions it therefore might throw. Since the possible errors are an implementation detail you should not need to care. The types of exceptions that can occur therefore should be restricted to a certain set of exception base classes and their derivates. If a developer does not know what that set is or if it is poorly designed or documented, she might be compelled to write a ton of catch handlers including a catchall in case she missed a type:

void foo() {
  try {
    doSomething();
    doSomethingElse();
  }
  catch (MyException& me) {
    //handle this one
  }
  catch (SomeOtherException& soe) {
    //handle this one, too
  }
  catch (SomeExceptionIAmNotSureOf& e {
    //better be safe than sorry...
  }
  catch (...) {
    //you know Justin? Just in Case?
  }
}

Ugh. The two simple lines of logic are almost invisible between a ton of error handling. And for sure, the catch handlers will do almost the same and you have a nice example of code duplication. Therefore the set of exception base classes used in a library should be as small as possible, preferably one. Two is acceptable, too, e.g. if you use a lot of standard library features that can throw exceptions but don’t want to derive your own exception classes from `std::exception`.

If you have only one common exception base class, you can limit the number of catch handlers to that class plus maybe one or two special classes that you want to handle in a special way. (Just make sure you catch the derived exceptions before the exception base class.)

Provide a well defined set of exception classes that may be used in your code. Any exception thrown in your code should be of or derive from one of those classes.

Catching but not handling exceptions

Having restricted the number of catch handlers per try let’s have a look at the catch handlers that don’t really react to the error but do something else.

Cleaning up

One of the best known, overused and in my opinion completely mislead example for exception handling is cleaning up stuff. It ranges from freeing allocated memory over closing files, database transactions, to resetting values that have temporarily been changed. In general, the pattern is beginning some action, executing the possibly failing operation, and then either finishing the action or reversing it, depending on if an exception has been thrown or not:

void foo() {
  startSomething();

  try {
    thisMightThrow();
  }
  catch(/* whatever might be thrown */) {
    reverseSomething();
    throw;
  }
  
  commitSomething();
}

The committing part may be trivial or completely missing, but that is not the point. The point is that C++ has a very important language feature that is meant and perfectly able to handle any cleanup that has to be done: Destructors. You might say that destructors are only meant to do the cleanup after an object of the class has done its purpose, but you should think of it the other way round: If you have something to be cleaned up, make it a class with the proper destructor.

There are many classes whose sole purpose is providing a destructor that does the cleanup. Best known of these are smart pointers and scoped locks. The pattern is commonly known as “RAII”, meaning “Resource Acquisition Is Initialization” and coined by Bjarne Stroustrup himself. However, it is not reserved for resources like memory, files and locks, it can be applied to anything that has to be cleaned up. Having to clean up something means to have a responsibility, therefore Jon Kalb modified the meaning of RAII in a brilliant talk: “Responsibility Acquisition Is Initialization”. Make sure to watch all three parts of that talk, it is worth every second.

With RAII, the above code could look like this:

struct SomethingRAII {
  bool _needCleanup;
  SomethingRAII() : _needCleanup(true) {
    startSomething(); 
  }
  ~SomethingRAII() {
    if (_needCleanup) reverseSomething();
  }
  void commit() {
    commitSomething();
    _needCleanup = false;
  }
};

void foo() {
  SomethingRAII mySomething;
  thisMightThrow();
  mySomething.commit();
}

That’s it. The whole function has been shrunk to three lines, because you don’t have to care about the “what if there is an exception” case any more. It has several advantages:

1. It’s easier to read, because usually you only want to know about the normal non-exceptional things that happen. If a reader is interested in the cleanup and the RAII class has a good name he will know that he has to look into the destructor.
2. It does the cleanup always, for everything that might be thrown. You can’t forget to catch any newly introduced exceptions or something you did not even know you could catch, e.g. access violations (some compilers throw them like ordinary exceptions).
3. It follows the Separation of Concerns and Single Responsibility Principles: The function contains only the normal logic that has to be executed and not a mixture of normal logic and cleanup for error cases.

Use RAII classes instead of try/catch  for cleanup in the presence of exceptions.

Adding information to the exception

This is not as clear-cut as cleanup. I often see catch handlers that just add some plain text to an exception’s `what()` message and rethrow it:

void bar() {
  try {
    doSomething();
  }
  catch (MyException& me) {
    throw MyException("Exception in void bar(): " + me.what());
  }
}

This is pure debugging information and adds no value to the program, because you normally can’t act on it at the location where the exception is really handled except when you are in a debugging session. Instead, it buries the interesting action inside the try block, making the function less readable. If you need such information once to debug a tricky problem, then by all means add the try/catch, but don’t check it in, because you hopefully won’t ever need it again.

However, sometimes you might want to add information that is needed to handle the exception correctly, e.g. to call the same function with different parameters. In my experience that is at most very rarely the case, but it would be an example where adding information is acceptable.

Don’t misuse exceptions for debugging purposes.

Changing the exception type

There are two kinds of situations where I have seen catch handlers that change the exception type. One is at the boundary of (third party) libraries, the other is at arbitrary locations in someone’s code, often together with the “adding information” example above and including “catchalls”, i.e. `catch(…)` to change anything that might come flying into something that is considered more meaningful.

Type change inside a library

Changing an exception’s type inside a library (i.e. not at library boundaries) usually either means the original exception did not have the correct type or it can not be caught at the handler because the exception type hierarchy is messed up in one way or the other. As written in the first paragraph, if exceptions are the preferred error handling mechanism in a library, the library should define a set of exception base classes and any exception thrown inside the library should derive from those.

Another reason for changing an exception’s type inside a library may be to add information, but since the catch site will usually not know exactly what the original type was, it also destroys some information. In addition, as written above, adding information is often only used for debugging reasons and should be avoided in production code.

Similar to changing the type of an exception is a complete change of the error handling method, e.g. switching between exceptions and return codes or state variables. For the sake of consistency and maintainability, you should stick to one method of error reporting throughout your library.

Be consistent in your use of exceptions.

Type change at library borders

In contrast to type changes inside a library, I consider type changes at library borders a good practice. The reasons are encapsulation and consistency. If you use a third party library, you will either want to restrict that use to a small set of wrapper classes, or you will use it throughout your code except for the interfaces of your library. After all, you don’t want clients of your library to be dependent on a third party library that is only an implementation detail. Therefore you have to catch and translate exceptions thrown by the third party library either in your wrapper classes or hidden in your interface classes.

A special case of library borders are callbacks and event handlers you provide to other libraries. The manufacturer of those libraries, e.g. a GUI framework, can not know what kind of exceptions you use, and they can not prepare for them except using a catchall and ignoring all information the exception might provide. If not explicitly documented otherwise, assume that other libraries expect your callback and handler functions to be `noexcept`. Some libraries may provide an exception base type they can handle, so you could change your exception into a derived type of theirs, but if possible you should prefer to handle the error instead of letting it progress into unknown territory.

Exceptions are part of a library’s interface but can be leaked more easily. Encapsulate them properly.

Handling exceptions

Actually handling exceptions is usually not very hard, since you usually know what you have to do if an exception occurs. Among the usual reactions to an exception are:

1. Logging the error, e.g. writing it into a log file and/or notifying the user with a message box or something similar.
2. Ignoring the error, because the tried action was not vital to the function.
3. Trying to get the desired behavior by doing something else.

The hard part is to determine where in the code you can actually do something about them. I have seen code where a series of actions is performed one after the other. If one action did not succeed, the other actions could not be performed properly, so the author did introduce a state variable that was set to fail if an action did not succeed and each action had an early return if that variable was set to fail. In addition, each action had a try/catch block where the catch handlers set the state variable:

class X {
  bool mbOK;
public:
  void foo() {
    mbOk=true;
    action1();
    action2();
    action3();
    //...
  }
private:
  void action1() {
    if (!mbOK) return;
    try {
      doSomething();
    }
    catch (SomeException& se) {
      mbOk = false;
    }
  }
  //etc...
};

It was a vast multiplication of the same logic throughout all of those functions. The reason was simply that the error handling had been done too often, too early, too deep in the call hierarchy. It should have been done one level up, in `foo()`. If you look closely, the functions did not really react on the error. Instead, they just set a flag for someone else to react on. This is not error handling, it is error translation, from exceptions to a state variable. That is often the case when exception handling occurs at the wrong place: No real action is taken, because it is too early to completely handle the error.

Don’t catch exceptions too early. Only catch them if you can really do something about the error.

Conclusion

In my experience, there are only two, maybe three occasions in which you should use `try`/`catch`: Error translation at library borders and complete error handling at the place where you have all the information needed to act properly. The third case would be adding information that is needed at the catch site, but I have never seen that one in production code.

There might be other cases I have not come across yet, so I would be happy if you have examples.