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

Designing With Exceptions

When implementing the packages which make up your application, such as your core graphics engine, it is very useful to define an exception hierarchy to utilize. This is useful for delineating kinds of exceptions as well as translating error codes into useful string messages. An example of this is the standard exceptions of the Standard C++ Library.

A simple base class exception type can contain an error message string into which you can place your exception information. Specifying constructors which take parameters that specify the file and line number ( which typically can obtained from __FILE__ and __LINE__ ) and a string message allows for an easy way of storing the origin of the exception. You can also put a simple method for logging the exception which can be called in the constructor of a concrete exception class.

I've also defined exception classes which translate DirectX error codes into a human readable message. If a component in the game engine package throws an exception it is always of a type derived from the base exception class of the package.

In general, if you are going to throw an exception, you might as well gather up as much knowledge about the exception then because you are already paying a huge performance penalty for throwing the exception. Also, if the act of throwing your exception happens to cause memory exhaustion, there is guaranteed to be enough memory free to throw a bad_alloc exception. My experience has been that you'll likely get terminated by the operating system before bad_alloc is thrown, however in either case you're already in a world of hurt.

I'll admit that I've opted-out of using exception specifications in my DirectX wrapper package in order to avoid adding superfluous try blocks.

Also, since the exception classes themselves log the error message I can make my catch blocks either catch-all handlers or for my base exception class and still log exception information automatically. It is probably best to use the specific handler in places where only your own exception classes will be thrown and use the catch-all when making calls into APIs which may be throwing anything; this second case includes calling new() and its potential throw of bad_alloc. And I generally have one catch handler for the try block in order to simplify program flow control.

Next : "Resource allocation is initialization" or Stack-Based Resource Management