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
We assume that the specification of a component includes its exceptional specification. The latter defines the expected behaviour when some abnormal, but anticipated, conditions occur. The exceptional specification associates anticipated exceptional conditions with a number of declared exceptional exit points (Section 3.1). A declared exceptional exit point, when taken, is signalled by an exception of corresponding declared exception type. The semantics of a declared exception is defined by the specification and it is part of the component's interface specification. Any correct implementation of a specification should include detection of the anticipated exceptional conditions. However, a more robust implementation may include the detection of exceptional conditions that are not anticipated by the specification. For these unanticipated exceptional conditions, the component developer should define undeclared exceptional exit points.
Undeclared exceptional exit points are problematic because different correct implementations of the same specification may define different undeclared exceptional exit points. This may result in architectural mismatches when one tries to integrate such components in a system. It is a current practice to associate undeclared exceptional exit points with exceptions of arbitrary types that are defined by the component developer or are propagated from lower level components. This ad hoc scheme for signalling unanticipated exceptional conditions may cause, during system execution, the raising of undeclared exceptions without proper contextual information and failure semantics. In these a circumstances, the system integrator has little opportunity for introducing fault tolerance in the integrated system.
Our approach to solve this problem comprises two complementary strategies: a global (inter-component) strategy and a local (intra-component) strategy. The intercomponent strategy is concerned with system integration and is applied to configurations of components and connectors. The intra-component strategy is concerned with component development and is applied to individual reusable software components. To allow these two strategies to be applied in conjunction, they share a common abstract exception type hierarchy for precisely expressing the failure semantics of a component or connector.