- Basic Terminology
- Defects and Faults that Lead to Failure
- Defect Removal Versus Defect Survival
- Deriving New Exception Classes
- Protecting the Exception Classes from Exceptions
- Conclusion
Protecting the Exception Classes from Exceptions
The exception objects are thrown when some software component encounters a software or hardware anomaly. But exception objects themselves don’t throw exceptions. This fact has many implications. If the processing of the exception is complex enough to potentially cause another exception to be generated, the exception processing should be redesigned and simplified wherever possible. The exception handling mechanism is unnecessarily complicated when exception handling code can generate exceptions. Therefore, most of the methods in the exception classes contain the empty throw() specification:
// Class declaration for exception class class exception { public: exception() throw() {} exception(const exception&) throw() {} exception& operator=(const exception&) throw() {return *this;} virtual ~exception() throw() {} virtual const char* what() const throw(); };
Note the throw() declarations with empty arguments. The empty argument shows that the method cannot throw an exception. If the method attempts to throw an exception, a compile-time error message is generated. If the base class cannot throw an exception, the corresponding method in any derived class cannot throw an exception.