A Systematic Approach for Structuring Exception Handling in Robust Component-Based Software
This article addresses the systematic incorporation of exception handling into component-based systems. By "component-based", one can infer "object-oriented" since the use of libraries of classes, such ast STL and JCL, can be seen as the use of components, building blocks, while constructing large-scale software systems. Read this article in its entirety to get a sense of how to put exception handling to good use.
4. The Proposed Exception Handling Strategy
4.1 Abstract Exception Type Hierarchy
Figure 3 shows the proposed abstract exception type hierarchy. This hierarchy can be easily mapped to existing object-oriented programming languages where exceptions are defined by classes, such as C++, Java, and Delphi. On the top of the hierarchy is Exception, the super class of all exception classes. A component's execution terminates at a declared exceptional exit point by signalling an exception of the abstract type DeclaredException. All the exceptions of type DeclaredException, as well as its subtypes, should be explicitly declared in the signatures of operations that may signal them. The failure semantics associated with the abstract exception type hierarchy is based on the exception types defined for the idealized faulttolerant component and coordinated atomic actions.
The UndeclaredException hierarchy is used by a component developer to attach failure semantics to exceptions associated with exceptional conditions that are not anticipated by the component's specification. These abstract exception types also allow system integrators to incorporate handlers in a component-based system to deal with these undeclared exceptions in a systematic way. UndeclaredException has two direct subtypes: RejectedRequestException and FailureException. Exceptions of the RejectedRequestExceptiontype are used to signal that a request received from a client could not be processed, due to a pre-condition violation, and that the system's state has not been affected.
Exceptions of the type FailureExceptionindicate that the implementation of the component failed to process a valid request. FailureException has two subtypes: RecoveredFailureException and UnrecoveredFailureException. Exceptions of the type RecoveredFailureException are used to indicate that, in spite of the fact that an error occurred, the component has been left in a consistent state. Instances of UnrecoveredFailureExceptionare used to indicate that a failed operation may have caused undesirable effects in the state of the component.