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.3 Inter-component Exception Handling Strategy
The inter-component strategy is applied during the assembly workflow of a CBD process (Section 3.3). This strategy deals with the integration of pre-existing components into a new configuration. It is based on connector-level exception (CLE) handlers that are associated to architectural connectors in a specific software configuration. Figure 6 shows the internal structure of an architectural connector with a CLE handler and how it connects a client component to a server component.
CLE handlers are responsible for: (i) providing error recovery and masking at the architectural level exceptions that cannot be handled within the context of a specific component; and (ii) resolving failure semantics mismatches between server components and their clients, for instance, when a server component signals an exception that is not expected by its client. A CLE handler should be capable of dealing with all exceptions signalled by server components. A possible scenario of exception handling at the architectural level is a configuration that includes two or more redundant server components. In this scenario, a fault-tolerant client/server connector could be used as a mediator between client components and the redundant servers. Upon receipt of an exception from a server component, the associated CLE handler can try to mask the exception by re-invoking the same service on an alternate (replicated or diversely designed[1]) server component. Moreover, if a server component successively fails, generating too many exceptions, the connector may choose to isolate it and forward all subsequent requests to an alternate server component.
CLE handlers are also responsible for translating the types of unmasked exceptions from the domain of the server component to the domain of the client component, before propagating them. Exceptions that require no further adaptation are automatically propagated. When automatic propagation is not possible, CLE handler can create a new exception that encapsulates the unmasked exception raised by the server component. The type of the propagated exception should be: (i) one of the exception types declared for the operation requested by the client component, as defined by its required interface, or (ii) a subtype of UndeclaredException. (Figure 3).
| Exception El signalled by the server component | Type of exception propagated to the client component |
|---|---|
| El is declared in both the required interface of the Client component and the provided interface of the Server component | El (it may be automatically propagated) |
| El is declared in the provided interface of the Server component and there is a corresponding exception type E2 (compatible semantics) declared in the required interface of the Client component | E2 (e.g. El and E2 have a comM01) ancestor, 23, or 22 is a super type of El) |
| El is declared in the provided interface of the Server component and can not be translated according to the two rules stated above | A subtype of RejectedRequestException, UnrecoveredFailureException, or RecoveredFailureException, according to the failure semantics associated to El (Section 4.1) |
| El is a subtype of UndeclaredException | El (it may be automatically propagated) |
| El is not declared in the provided interface of the Server component and is not a subtype of UndeclaredException | A subtype of UnrecoveredFailureException |
Table 1: Guidelines for exception translation by a connector
Table 1 provides guidelines for exception translation followed by architectural connectors. These guidelines are based on the configuration depicted in Figure 6 and on the premise that the Server component signalled an exception E1 in response of a service request received from the Client component.
CLE handlers are the best candidates for coordinating the exceptional behaviour specified for the integrated system. This way, the implementation of the exceptional behaviour of the integrated system is less dependent of any particular version of a component's implementation. Moreover, connectors are developed during the assembly workflow, when knowledge about the integrated system's requirements, the exceptional behaviour specified for its components, and the way they should interact, is available. Being so, CLE handlers can take reasonable recovery actions based on the abstract types of the undeclared exceptions they may receive (Section 4.1). As these recovery actions are system-dependent, this separation of concerns also improves component reuse.