When to signal an exception

Signal an exception when a condition occurs that prevents your function from returning its normal result. Of course, part of designing a function is deciding what's a normal result and what's an exception. Stroustrup's rule of thumb is a good one: use exceptions for exceptional or unusual conditions, not as novel flow of control techniques. Think of an exception as something that has message text explaining the problem associated with it.

NOTE The Taligent standard requires that all error conditions in the Taligent Application Environment be reported through exceptions, not through error codes.


Do not throw exceptions in destructors, and do not call anything that might throw an exception unless you're prepared to catch it and deal with it (see the next section, "When to recover an exception"). Destructors that exit with an exception never finish executing, and the uncleaned resources are lost.

Additionally, the ISO/ANSI draft standard states that if the exit occurs during a stack unwind (while handling an exception), and while searching for an exception handler, the special function terminate() is called. As you might gather from the name, terminate() takes rather draconian measures. Although you can install your own terminate function instead, it cannot be done in a clean way by library software, but must instead be left to the application developer.

[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker