Contents  Overview  Implications  Specifications  Designing With  Exceptions  Resources  Interactions With  Threads  Real-Time Systems  Philosophies  Potential Pitfalls  Printable version

Exception Specifications

When I first started learning about exception specifications I flip-flopped quite a bit about how useful they are. I could see the benefits from a client perspective, but the implications imposed on the component writer made me reconsider where exactly they should be applied.

The essential benefit of an exception specification is that clients of a component know exactly what exceptions may be thrown from a function or a method. This can be great from the client perspective of handling exceptions, because the client knows exactly what exceptions, if any, may be thrown. However, as a component implementer, the cost of guaranteeing meeting that expectation may be high.

For example, let's consider the following code.

class MyClass
   {
   void MyMethodWithOnlyOneExceptionSpecification(void)
       throw (MyExceptionClass);
   void MyMethodThatThrowsNoExceptions(void) throw();
   };

As a client of MyClass you can say, "Great! I only have to worry about MyExceptionClass exceptions coming out of MyMethodWithOnlyOneExceptionSpecification() and no exceptions will be thrown from MyMethodWithThrowsNoExceptions()."

In actuality, the first exception specification says that exceptions of type MyExceptionClass or derived from MyExceptionClass may be thrown from that method. But maybe that isn't such a big deal after all. As a client you may only care about the generic MyExceptionClass.

However, to implement this specification we will most likely have to use a try/catch block within the implementation of these methods to enforce the exception specification. Otherwise we run the risk of std::unexpected() being called, the default behavior of which is to terminate the application. Clients of our class may override this default behavior, but as a component implementer we cannot make this assumption. And since aborting the program execution is usually much more catastrophic than letting an exception propagate all the way up we have to fall back on using the try block. This means you could be imposing performance penalty for your exception specification, above and beyond the performance penalty of the exception specification, that is. Granted, maybe you could conditionally compile the try block in debug versions of your component and or package, but that seems rather dangerous.

Because of this problem, it seems best to avoid exception specifications for most components. So where does it make sense to use exception specifications? My experience has indicated that if you need to enforce an exception specification, either of a specific exception class or no exceptions, then you should probably do so at the highest level components of your package. And do so only when you know you must. Another potential location for using exception specifications is in thread routines as throwing an exception out of a thread routine is analogous to throwing one out of main().

Real-time systems, such as games, may benefit from not permitting exceptions to be thrown from certain portions of their API. This is because of the effect on flow control exceptions have. In this case it may be beneficial to use exception specifications to enforce this.

Next : Designing With Exceptions