Conclusiones Implicaciones para la práctica clínica

2.4

An Exception Handling System for Component-

Based Applications

In this section, we present the main characteristics of our exception handling system and discuss our design decisions to address the requirements discussed in Section 2.3. We follow the guidelines established by Garcia et al [71], and describe ALEx in terms of the following features: exception representation, handler definition, handler attachment, exception propagation, handler search, and continuation of the control flow.

In our approach, an iC2C (Section 2.2.3) can represent a component, connector or con- figuration which has an architectural-level exception handler attached. We also employ the C2 architectural style for describing examples of architecture configurations, since it is leveraged by the concept of iC2C. Exceptions are wrapped by C2 notifications in order to be propagated along the layers of the system’s architecture. Notifications representing exceptions are called exception notifications, and they are distinguished from normal no- tifications. Furthermore, we define regular C2 components as C2 components that: (i) do not send exception notifications, and (ii) will not recognize an exception notification received as being the signalling of an exception. In other words, a regular C2 component will recognize an exception notification as an ordinary notification sent in response to a request issued prior to the receipt of the notification. We will not consider special cases, such as regular C2 components capable of sending exception notifications.

Hereafter, we use the term “exception” to designate both exceptions and exception notifications, since the latter is simply an implementation concept which is not directly related to the EHS. For situations where implementation issues are relevant, we highlight the difference between the two terms.

2.4.1

Exception Representation

According to the taxonomy defined by Garcia et al [72], ALEx represents exceptions as data objects, that is, objects which are used for holding context information which is relevant for their handling. More specifically, we define exceptions as messages, which constitute a suitable abstraction for component-based systems. Exceptions are raised by calling a specific keyword (in our Java implementation, the throw keyword).

Different types of exceptions are organized hierarchically as classes. The class Ar- chitecturalException is the root of this hierarchy. ALEx defines two subclasses of Archi- tecturalException, FailureArchitecturalException and InterfaceArchitecturalException, which correspond to the failure exceptions and interface exceptions of an idealised fault-tolerant component, respectively. Any raised exception which is not of type InterfaceArchitectura- lException is treated as a failure exception, indicating that the architectural element may

2.4. An Exception Handling System for Component-Based Applications 31

public class AbnormalActivity ... {

public Message handleException(IOException e){ // Body of a handler for IOException.

} ...

public Message handleException(ArchitecturalException e){ // Body of the generic handler. Must be implemented! }

... }

Figura 2.3: Definition of handlers in ALEx.

be in an inconsistent state. Interface exceptions must be explicitly signaled.

The signatures of the operations in component interfaces should explicitly indicate the exceptions they raise. According to the work of Garcia et al.[72], this practice leads to better readability, modularity, maintainability, reusability and testability. Further- more, explicitly declaring the exceptions raised by a component allows static checks to be performed by means of analysis tools, increasing dependability.

2.4.2

Handler Attachment and Definition

Our EHS supports multi-level attachment of handlers, that is, handlers may be associated with: (i) a component, (ii) a connector, (iii) a configuration. Figure 2.2 shows a set of exception handlers, represented by the AbnormalActivity component, attached to a component, represented by the NormalActivity component. The abnormal activity of a component is defined by a class which implements a set of methods, each one representing an exception handler. Furthermore, each of these classes should define at least a default handler, capable of handling an exception of the ArchitecturalException type. Figure 2.3 shows a partial definition of an exception handler which handles exceptions of types IOException and ArchitecturalException.

Exception handlers may also be attached to configurations, as well as to components and connectors. The possibility of attaching handlers to specific configurations allows that different exception handling contexts be defined within a single application. This is achieved by nesting exception handlers, as illustrated by Figure 2.4, where an iC2C is used as the NormalActivity component of another iC2C. This feature is specially useful for systems which have critical regions that require a higher level of fault tolerance.

2.4. An Exception Handling System for Component-Based Applications 32

Figura 2.4: Nesting exception handling contexts.

2.4.3

Exception Propagation and Handler Search

Our exception handling model adopts explicit propagation of exceptions. The benefits of this approach are discussed in the work of Garcia et al.[72]. In ALEx, the handling and propagation of an exception depends on whether it is a failure exception or an interface exception. When an iC2C raises a failure exception, its handling is limited to the handlers within the same iC2C (that is, its AbnormalActivity component). If the exception can not be handled, then the predefined exception FailureArchitecturalException is further pro- pagated. A handler may also explicitly resignal the exception to a component in a lower layer of the architecture. In Figure 2.4, exceptions raised by the NormalActivity compo- nent of the innermost iC2C are handled by the AbnormalActivity component within it. If the internal handling fails, the handler may resignal the exception to the AbnormalAc- tivity component of the outermost iC2C. In case an exception reaches the lowest level of an architecture, an exception handler for the entire system should be executed.

An interface exception raised upon the receipt of a service request is not handled by the component, since it does not indicate that the component is faulty. In this case, the exception is propagated to the client component which issued the request. The client component handles this exception in the same manner as a failure exception, since it possibly indicates a fault within the client component.

The search for handlers for a failure exception raised by the NormalActivity component of an iC2C is defined as follows:

1. The EHS tries to find a specific handler for the exception in the AbnormalActivity component within the same iC2C. Handlers are searched according to the class

2.4. An Exception Handling System for Component-Based Applications 33

hierarchy defined for exceptions:

if an exception of class C is raised in a given system, a handler for exceptions of class C will be searched;

if none is found, the EHS proceeds searching for a handler for an immediate superclass S of C;

if none is found, the EHS searchers for a handler for an immediate superclass of S, and so on.

2. If no specific handler is found, the default handler is selected. This handler may actually handle the exception or simply resignal it.

3. In the latter case, if the iC2C which raised the exception is wrapped by another iC2C (as is the case in Figure 2.4), step 1 is repeated for the outermost AbnormalActivity component. Otherwise, the exception is propagated downwards the architecture, to the client component which issued the request that triggered its signaling. Step 1 is then repeated for the AbnormalActivity component of the client component. The search for handlers for an interface exception raised by the NormalActivity com- ponent of an iC2C proceeds in a similar manner, except that steps 1 and 2 are not initially performed.

2.4.4

Continuation of the Control Flow

ALEx _{adopts the termination model[52], that is, if during the processing of a service}

request a component raises an exception and it is successfully handled by another com- ponent, execution is resumed by the latter.

Figure 2.5 presents an example of an architecture composed by two idealised C2 com- ponents (ClientComponent and ServerComponent), and a connector linking them. Figure 2.6 shows a UML seq. diagram illustrating a scenario where the control flow continues after an exception is successfully handled. The following steps describe the diagram:

1. ClientComponentrequests a service from ServerComponent;

2. ServerNormalActivity tries to handle the service request;

3. ServerNormalActivity raises an exception which is received by ServerAbnormalActivity;

4. ServerAbnormalActivitytries to handle the exception;