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.
3. Background
3.1 Exception Handling
The complexity introduced by fault tolerance in software systems motivated the development of a well-known style of system structuring known as idealised fault-tolerant component (IFTC). An idealised fault-tolerant component is a piece of software (a class, module, component, or a whole system) where the parts responsible for normal and exceptional activities are separated and well defined. Figure 1 presents the structure and flow of control of the IFTC. Upon receipt of a service request, an IFTC produces three types of responses: normal responses in case the request is successfully processed, interface exceptions in case the request is not valid, and failure exceptions, which are produced when a valid request is received but cannot be successfully processed.
Exception handling is a very popular technique for incorporating fault tolerance into software systems. It allows developers to structure the redundant code that is added to deal with the exceptional conditions that may occur, separating it from the code responsible for the normal operating flow. An exceptional condition is signalled by means of an exception that is raised by the normal code. When this occurs, the underlying EHS interrupts the normal flow and transfers the control to an appropriate exception handler, which can deal with the exceptional conditions associated with the type of the exception raised. Handling contexts are regions of the code in which exceptions of the same type are treated in the same way.
Flaviu Cristian presents a synthesis of the termination exception-handling paradigm for sequential programs. The exception handling systems of C++, Java, and C# adhere to this model of exception handling. The Design by Contract approach provides a different view of exception handling, which is supported by the Eiffel language.
The main focus of Cristian's approach is robustness, which is a means to achieve fault tolerance. A robust program should be prepared to handle all possible inputs, in conformance to a specification. A program may terminate normally, at its standard exit point, or exceptionally, at one of its exceptional exit points. In the second case, an exception should be signalled. A program specification defines the standard exit point and zero or more declared exceptional exit points. A declared exceptional exit point corresponds to an abnormal condition that is anticipated by the designers. There may also be undeclared exceptional exit points, which result from unanticipated abnormal conditions (or design faults). An undeclared exceptional exit point is signalled by an undeclared exception.
The main goal of the Design by Contract approach is correctness, that is, it focuses on avoiding faults, not tolerating them. A routine should not be prepared to handle all possible inputs, but only those specified by the precondition of its contract. A routine has a single contract that specifies a single exit point. This exit point is taken whenever the routine succeeds to fulfil its contract. Exceptions are only used to signal design faults, which are detected by means of executable assertions that describe the contracts.