7.4 Recognizing Where to Handle Defects versus Where to Handle Exceptions

In general, software defects (which are the result of programmer error) should be detected and corrected during the testing phases defined in Table 7-1.

Table 7-1. Types of Testing Used During the Software Development Process

Types of Testing	Description
Unit testing	The software is tested one component or unit at a time. A unit is described as a software module, a collection of modules, a function, a procedure, an algorithm, an object, or a program.
Integration testing	An assembly of components of the software is tested. The components are collected into logical groups and each group is tested as a unit. The groups can be subjected to the same tests. As groups pass the test, they are added to an assembly, which in turn must be tested. The number of elements that must be tested will grow combinatorially.
Regression testing	Modules are retested once they are changed. Regression testing guarantees the changes to the component do not cause it to lose any functionality.
Stress testing	Testing that pushes a component or system to and beyond its limits. This will include testing boundary conditions, which help in determining what happens at the boundaries.
Operational testing	Test the system in full operation. The software is placed in a live environment to be tested under a complete system load. This testing is also used to determine performance in a totally foreign environment.
Specification testing	The component is audited against the original specifications. The specification dictates what components are involved in the system and the relationships between those components. This is part of the software verification process.
Acceptance testing	Testing performed by the end user of the module, component, or system to determine performance. This is part of the software validation process.

Through the process of testing and debugging, defects should be identified and removed. On the other hand, exceptions are handled during execution of the program at runtime. We also distinguish between exceptional conditions and unwanted conditions. For instance, if we have designed a program that will add a list of numbers typed in by the user and the user types in some numbers and some characters that are not numbers , then this is an unwanted condition, not an exceptional condition. We should design programs to be robust through input validation so that the user is forced to enter the data that our program requires for proper execution. If part of a program that we design saves information to external storage and the program encounters an out-of-space condition, then the out-of-space condition is an unwanted situation, not an exceptional or extraordinary condition. We reserve exception handling for the unusual, not the unwanted. We reserve exception handling techniques for the unanticipated . Situations that are unwanted but have a reasonable probability should be handled by ordinary program logic such as the following:

 If Input data not acceptable then   request input data again else   perform required operation end if

Checking conditions in this way is part of the fundamental art of programming. This kind of programming prevents problems from happening. It certainly doesn't rise to the definition of exception. There is a difference between defects and exceptions and between exceptions and unwanted conditions. Defects are dealt with using testing and debugging. Unwanted conditions are handled within the confines of the regular program logic and exceptions are handled using exception handling programming techniques. Table 7-2 contrasts the difference between the characteristics of error handling, exception handling, and the handling of unwanted conditions.

Table 7-2. Differences between the Characteristics of Error and Exception Handling and the Handling of Unwanted Conditions

Error Handling	Exception Handling	Handling Unwanted Conditions
Logical errors discovered during design and testing Correct programs do not contain errors Use program logic to anticipate and correct errors Normal flow of control is maintained	Describes unanticipated conditions during execution time Correct programs can encounter exceptions Use exception handling to recover from exceptions Normal flow of control is disrupted	Describes unwanted conditions that have a reasonable probability of occurring during execution time Correct programs may encounter unwanted conditions Use program logic to correct unwanted conditions Attempt to maintain normal flow of control

The goal is to build error handling and exception handling components that can then be integrated with the other components that make up our parallel or distributed programs. The error handling and exception handling components must have the capability of identifying and reporting what the problem is as well as recovering from or correcting the problem. The recovery and correction can involve everything from prompting the user to reenter the data to restarting a subsystem within the software. Recovery and correction efforts can involve extensive file processing, database backouts, network rerouting, processor masking, device reinitialization, and for some systems, even hardware part replacements . Error and exception handling components can take on a range of forms, from simple assertion statements to smart agents whose sole purpose it is to anticipate failures and prevent them before they happen. A significant portion of any serious piece of software will be devoted to the error and exception handling components. Figure 7-3 shows the architecture for a simple error handling component.

Figure 7-3. Architecture of a simplified error handling component.

graphics/07fig03.gif

Component 1 in Figure 7-3 is a simple map component that contains a list of error numbers and their descriptions. Component 2 contains a map object that maps the error numbers to jump locations, functions, or subsystems. Depending on what the error number is, component 2 is used to determine where to transfer. Component 3 is a map that maps the error numbers to the report hierarchy and report logic. The report hierarchy contains who or what should be notified of the error. The report logic determines what the notification should be. Component 4 contains two map objects. The first object maps the error numbers to objects whose purpose it is to correct some failure condition. The second object maps error numbers to objects who will return the system to a stable or at least a partially stable state. The simple error handling component in Figure 7-3 can be applied to software of all sizes and shapes . How the error handling and exception handling components are used will be determined by the amount of software reliability desired.