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.2 Intra-component Exception Handling Strategy
The intra-component strategy is applied during the provisioning workflow of a CBD process (Section 3.3). At this stage, concrete components are selected in order to materialize the abstract components specified in the software architecture of the system being developed. As discussed earlier, these components may be either existing or newly developed components. Our intra-component strategy described applies to both situations: the adaptation of existing components and the development of new components.
When a component is built from scratch, its implementation is under control of the software developer. Figure 4 depicts the proposed internal structure of a component with one provided interface and one required interface. The employed notation is UML 2.0. The implementation classes implement the operations specified by the component's provided interface. Furthermore, these classes may have dependencies that are explicitly represented by means of the required interface of the component. In the proposed strategy, implementation classes are responsible for: (i) detecting exceptional conditions anticipated by the specification of the component and signalling exceptions of types declared in the provided interface of the component; (ii) signalling internal exceptions related to other exceptional conditions which are specific to the implementation of the component; and (iii) executing clean-up actions, when necessary. The types of exceptions raised by the implementation classes should be subtypes of DeclaredException and UndeclaredException, depending on whether the exceptional condition that was anticipated or unanticipated.
A façade class is associated to a provided interface and defines an access point to its implementation. When necessary, façade classes could be also responsible for serializing incoming requests, in order to transform the component in a damage confinement region. A façade class may also detect the violation of pre- and post-conditions for operations defined by its corresponding provided interface.
The intra-component strategy is based on application-level exception (ALE) handlers and boundary-level exception (BLE) handlers. ALE handlers are associated to implementation classes. They are responsible for handling three kinds of exceptions: (i) external exceptions of types declared in the required interfaces of the components; (ii) internal exceptions signalled by implementation classes; and (iii) internal exceptions signalled by the underlying infrastructure.
BLE handlers are responsible for dealing with exceptions that reach façade classes. Exceptions of types declared in the provided interface of the component, which are anticipated by its specification, are simply propagated by BLE handlers. These handlers also propagate exceptions of type RejectedRequestException, which signal an error in the request issued by the client. For other exception types, backward error recovery may be performed, in case it is available. If the component is left in a consistent state, an exception of type RecoveredFailureException is signalled, indicating that the state of the component is consistent. Otherwise, an exception of type UnrecoveredFailureException is signalled.
When an existing OTS component is reused, a wrapper should be created in order to avoid architectural mismatches (Section 3.3). In this case, the abstract architectural component is instantiated by a composite component wrapping the OTS component, as depicted in Figure 5. The OTS component may include its own exception handlers. All responsibilities that are associated to façade classes and BLE handlers in a component built from scratch, are associated, respectively, to provided interface interceptors and BLE handlers of the composite component. Moreover, a provided interface interceptor is responsible for adapting the OTS external interface to the provided interface specified for the abstract architectural component. Provided interface interceptors, together with the BLE handlers, are also responsible for mapping exceptions raised by the component's implementation to the abstract exception type hierarchy. The main responsibility of the OTS component is the implementation of its external interface.
