- Basic Terminology
- Defects and Faults that Lead to Failure
- Defect Removal vs. Defect Survival
- The Java Termination Model
- The Exception Handler
- Deriving New Exception Classes
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Defect Removal vs. Defect Survival
As the types of tests in Table 2 are performed on a piece of software, defects are found and removed from the software. The more defects found and removed during testing, the fewer defects encountered by the software during runtime. Defects encountered during runtime lead to failures in the software. Failures in the software produce exceptional conditions for the software to operate under. Exceptional conditions require exception handlers. So the balancing act is between defect removal during the testing stages versus defect survival during exception handling. Figure 1 shows the transformation from programmer error to exceptional condition in software requiring an exception handler.
)
Figure 1 Transformation from programmer error to exceptional condition in software requiring an exception handler.
Although we could favor defect survival over defect removal, the problem is that exception handling code can become so complex that it introduces defects into the software. Instead of providing a mechanism to help achieve fault tolerance, the exception handler becomes a source of failure. Choosing defect survival over defect removal reduces the software’s chances of operating properly. Extensive and thorough testing removes defects, thereby reducing the strain on the exception handlers. It’s also important to note that exception handlers don’t occur as freestanding pieces of code. They occur within the context of the overall software architecture. The journey toward fault tolerance in our software begins by recognizing the following facts:
- No amount of exception handling can rescue a flawed or inappropriate software architecture.
- The fault tolerance of a piece of software is directly related to the quality of its architecture.
- The exception handling architecture cannot replace the testing stages described in Table 2.
To make our discussion about exception handling clear and meaningful, it’s important to understand that the exception handling architecture occurs within the context of the software architecture as a whole. If the software architecture is inappropriate, incomplete, or poorly thought out, any attempt at after-the-fact exception handling is highly questionable. Further, if shortcuts have been taken during the testing stages—incomplete stress testing, integration testing, glass box testing, and so on—the exception handling code will have to be added to perpetually and will become increasingly complex, ultimately detracting from the software’s fault tolerance.
On the other hand, if the software architecture is sound and the exception handling architecture is compatible and consistent with the software architecture, a high degree of fault tolerance can be achieved. If we approach our goal of context failure resilience with an understanding of the roles that software architecture and testing play, we can move forward with determining how to take advantage of exception handling facilities in Java. Table 3 list the primary components of the Java exception handling facility.
Table 3 Primary components of the Java exception handling facility.
|
Component |
Description |
|
try |
Keyword used to identify a block of code that the program is attempting to execute. |
|
catch |
Keyword used to identify handlers designed to catch exception objects. |
|
throw |
Keyword used to throw an object of some type when control is transferred to an exception handler coded to deal with the type of object thrown. |
|
finally |
A block of code that must be executed after exceptions are thrown. It’s placed at the end of an exception handler. |
|
Exception classes |
Runtime exception and error families of classes. |