Some programs are quite simple (small utilities, for example). You might only need to take input and perform some processing. In these programs, you might attempt to allocate memory and fail, try to open a file and fail, and so on. It is acceptable in these programs to display a message and exit the program, allowing the system to clean up the mess, rather than to work hard to catch all exceptions and recover all the resources yourself. Basically, if you don’t need to use exceptions, you don’t have to use them^.

New exceptions, old code

Another situation that arises is the modification of an existing program that doesn’t use exceptions. You might introduce a library that does use exceptions and wonder if you need to modify all your code throughout the program. Assuming you have an acceptable error-handling scheme already in place, the most straightforward thing to do is surround the largest block that uses the new library (this might be all the code in main( )) with a try block, followed by a catch(...) and basic error message). You can refine this to whatever degree necessary by adding more specific handlers, but, in any case, the code you’re forced to add can be minimal. It’s even better, of course, to isolate your exception-generating code in a try block and write handlers to convert the exceptions into your existing error-handling scheme^.

It’s truly important to think about exceptions when you’re creating a library for someone else to use, especially in situations in which you can’t know how they need to respond to critical error conditions (recall the earlier discussions on exception safety and why there are no exception specifications in the Standard C++ Library)^.

Typical uses of exceptions

Do use exceptions to do the following:

·         Fix the problem and call the function which caused the exception again.

·         Patch things up and continue without retrying the function.

·         Do whatever you can in the current context and rethrow the same exception to a higher context.

·         Do whatever you can in the current context and throw a different exception to a higher context.

·         Terminate the program.

·         Wrap functions (especially C library functions) that use ordinary error schemes so they produce exceptions instead.

·         Simplify. If your exception scheme makes things more complicated, it is painful and annoying to use.

·         Make your library and program safer. This is a short-term investment (for debugging) and a long-term investment (for application robustness)^.

When to use exception specifications

The exception specification is like a function prototype: it tells the user to write exception-handling code and what exceptions to handle. It tells the compiler the exceptions that might come out of this function so that it can detect violations at runtime^.

Of course, you can’t always look at the code and anticipate which exceptions will arise from a particular function. Sometimes, the functions it calls produce an unexpected exception, and sometimes an old function that didn’t throw an exception is replaced with a new one that does, and you get a call to unexpected( ). Any time you use exception specifications or call functions that do, consider creating your own unexpected( ) function that logs a message and then either throws an exception or aborts the program^.

As we explained earlier, you should avoid using exception specifications in template classes, since you can’t anticipate what types of exceptions the template parameter classes might throw^.

Start with standard exceptions

Check out the Standard C++ library exceptions before creating your own. If a standard exception does what you need, chances are it’s a lot easier for your user to understand and handle^.

If the exception type you want isn’t part of the standard library, try to derive one from an existing standard exception. It’s nice if your users can always write their code to expect the what( ) function defined in the exception( ) class interface^.

Nest your own exceptions

If you create exceptions for your particular class, it’s a good idea to nest the exception classes either inside your class or inside a namespace containing your class, to provide a clear message to the reader that this exception is used only for your class. In addition, it prevents the pollution of the global namespace^.

You can nest your exceptions even if you’re deriving them from C++ standard exceptions^.

Use exception hierarchies