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.4 Method for our Exception Handling Strategy

This section describes a basic method for applying our exception handling strategy. This method was devised as an extension of a typical component-based process and is based on our previous experience in the use of exception handling for building fault-tolerant component-based systems.

Figure 7 shows the main artifacts added by our method and how they integrate in the development process shown in Figure 2. The method starts with the specification of the failure hypotheses and the exceptional behaviour expected for the system. During the requirements workflow, use case descriptions are analysed, in order to extract exceptional scenarios. Next, during the component specification workflow, these scenarios are used to specify the exceptional conditions that should be anticipated by the system and the types of the exceptions that might be signalled. Based on this, the various kinds of handlers (ALE, BLE and CLE) are specified, assigning to them responsibilities for dealing with exception types defined in the previous step. Finally, exceptions types and handlers are implemented and incorporated in the system, during the provisioning and assembly workflows.

 

Figure 7

 

The activities of the proposed method are described next with more details.

Activity 1: Specification of the failure hypotheses for the design of the system's exceptional behaviour. This includes the specification of exceptional conditions to be detected and the exception types that will signal these conditions. Although these two activities are not subject of the present work, they are essential for the development process. Activity 1 should be performed during the requirements workflow.

Activity 2: Design of the exceptional behaviour, allocating responsibilities to the various architectural elements and their exception handlers (ALE, BLE or CLE) and covering the failure hypothesis defined in Activity 1. Furthermore, generic handlers that deal with unanticipated exceptional conditions may be defined, for instance, to trigger backward error recovery in case an undeclared exception is signalled. This activity should be performed during the specification workflow.

Activity 3: Implementation of the subtypes of the exceptions specified by the abstract exception type hierarchy (Section 4.1), if necessary. These exceptions are dependent on the application and on the types of errors expected. This activity is performed during the provisioning workflow.

Activity 4: Implementation of ALE and BLE handlers. In Java and C#, this activity is performed by using trycatch blocks. We suggest that the actual handlers be implemented as methods in separate classes responsible exclusively for exception handling. In this manner, normal and exceptional behaviour are more explicitly decoupled and exception handlers can be reused. This activity is performed during the component provisioning workflow.

Activity 5: Implementation of CLE handlers. This activity is performed during the assembly workflow.