Life of Andrew

C++ is big – it has been said that any given programmer only ever uses about 40% of the language’s features. The trouble is that it is a different 40% for each person. Exceptions are a great example of this, some people swear by them while many coding standards specifically ban/discourage them (cf: google, mozilla). It is ironic that a feature designed to make code safer is sometimes regarded as being too dangerous to use.

Personally I like exceptions, but even I realise that they have there limitations. This post is an attempt to formalise some guidelines about when exceptions should be used and when they should be avoided beyond the usual language rules. I should mention at this stage that most of my experience is in desktop client/server software. C++ is used in all sorts of places these days, and what works on desktops and beefy servers may not suit the embedded world (for example).

When to Catch

My rule of thumb is “Do not let exceptions escape from a function you didn’t explicitly call yourself“. This includes destructors, callbacks, thread functions, WNDPROCs, and any other miscellaneous way your functions can be entered (it does not include constructors or virtual functions – exceptions are very useful in those). In general, all these things should catch and handle all exceptions.

Your program will die if an exception escapes a thread. If you are lucky your runtime will do something clever and your program will die painlessly but possibly the OS will have to dispatch the process messily. Either way, your users will not be impressed, so you should always wrap thread functions in try{}catch blocks. In the best case you might be able to signal that an operation failed to the main thread, which can restart it if required. In the worst case you can at least log what happened before exiting.

Lots of third part libraries communicate with your code using callbacks that you supply. You should always ensure that any exceptions are caught before returning back into third party code, since you can never be sure if the library does the right thing. C style libraries like LibCURL are right out, they will probably leak handles and memory as the stack is unwound. C++ libraries may (or may not) be better but could do things you do not expect, like swallow the exceptions themselves instead of letting them fall through (boost::iostreams). Also, some libraries actually call you back on a different thread (boost::asio) so the advice in the previous paragraph also applies here.

You should always be prepared to catch any exceptions that are documented by any C++ libraries you use, especially things like boost::filesystem which can throw at any time.

What to Throw

My advice is to create a small hierarchy that is derived from std::runtime_exception unless you are already using a custom exception class. Don’t try to get clever and throw std::string or char*. Design your hierarchy around how the exceptions are to be handled, rather than what can go wrong. For instance, if there are 5 different ways your program throw exceptions, but only 3 different things that can happen in response then you only need 3 types of exceptions.

In my experience, exceptions fall into two categories: recoverable and fatal. Recoverable exceptions will be caught within a layer, or perhaps the next layer up which can then reattempt the operation (or perhaps just log and ignore the problem if the operation was not crucial.) Fatal errors are usually not caught until the outer loop of the program, where they are logged before the program can be shutdown cleanly. In general, the exceptions you expect to recover from should derive from exceptions you expect to be fatal.

I tend to name my exception types based on how they are handled and what circumstance they represent, like so:

1
2
3
4
5
6
7
8
9
10
11
12
13

class UnrecoverableFileReadException : public std::runtime_error
{
	// thrown when a file cannot be read correctly, ie: the file exists but is misformatted
public:
	UnrecoverableFileException( const std::string& msg ):std::runtime_error(msg) {};
};
 
class FileReadException : public UnrecoverableFileReadException
{
public:
	// thrown when a file cannot be read but the user can be prompted to select another file
	TemporaryFileException( const std::string& msg ):UnrecoverableFileReadException(msg) {};
};

When throwing, always construct the exception with a sensible message if only for logging and debugging purposes. Normally this message would not be shown to the user since it will be hard to localise. Add additional members to your exception class if you want to include other information with the exception. Just remember that exceptions must be copyable.

1
2
3

ostringstream oss;
oss << "Could not open file " << filename << " the error was: " << errno;
throw TemporaryFileException( oss.str() );

If you really want to go the whole hog consider using boost::exception which builds upon similar ideas.

When to Throw

Exceptions should never be thrown if everything is running perfectly. Only when something goes wrong should throwing an exception be considered an option. I have seen code that threw exceptions to signal the end of an enumeration or to signal that the results of a query were empty – I consider these examples to be a terrible use of the feature. Remember that an exception is not just an error, but something really outside of normal program flow.

I also tend not to use exceptions for logic errors. If an algorithm can fail then the calling code should be prepared to handle a return code signalling an error. Likewise I would not throw if a database query returned no results – an empty result set is inside the bounds of normal program flow. However, I would consider throwing an exception if the query failed due to the database being unavailable.

The best places to use exceptions are in situations where your program is using resources that are not under your control, including anything to do with IO. Both files and network connections exist outside of your program and can become unavailable at any point due to any number of reasons. In many cases the problems are transient and all your program needs to do is try again in a few minutes – a program that quits each time the DNS, directory server, or external database cannot be reached will not survive for very long in any production environment. Exceptions allow you to back out of an operation without too much trouble and handle the problem in a sensible location.

One problem you might encounter is that is often hard to retrofit exceptions into code that wasn’t designed for them. In this case, my advice about not letting exceptions fall through 3rd party code also applies to legacy code that you own. This is not to say that you cannot use exceptions at all, just that you may have to take steps to keep exception handling within the layers of your application.