Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Exception Handler
The catch{} block is called the exception handler. A Java program can contain multiple exception handlers. Each exception handler is associated with one or more types, depending on the class hierarchy of the exception. Three of the basic functions of an exception handler are as follows:
- Register the type of exception(s) that it can handle.
- Record or in some way log what exception has occurred (sometimes this requires notification).
- Execute an appropriate exception handling strategy.
Exception handling strategies come in many shapes and sizes. The primary purpose of the exception handling strategy in the termination model is to bring the software back to a consistent state so that the software can continue to function at some acceptable level. Table 4 describes some common exception strategies.
Table 4 Commonly used exception strategies.
|
Exception Strategy |
Description |
|
Resource reallocation and deallocation |
Attempts to do the following:
|
|
Transaction or data rollback |
Undoes steps of an incomplete transaction, rolling the data back to a checkpoint where the data was valid. |
|
Operation retry |
Retries an operation: With original resources With alternate resources After a certain interval of time has passed After additional conditions have been met |
|
Redundancy and failover |
Turns over processing to other threads or processes that are operating in parallel with the current process. |
|
Notification for outside assistance |
Requests assistance from other software agents, human users, or other systems. |
The exception handling strategies that are used greatly impact the software architecture. This means that the exception handling strategy has to be included in the software design phase; it’s a fundamental part of the software architecture. If the overall software architecture is "brittle," the exception handling strategy is doomed. The semantics of the exception thrown are tied to the exception strategy implemented. Defining and understanding the semantics of an exception in the context of the software architecture is as important as deciding where to transfer control during the exception handling process. The Java language defines a collection of built-in exception classes with their own semantics. Table 5 shows how the Throwable Exception class is broken down.
Table 5 Breakdown of Throwable Exception classes.
|
Throwable Error |
Description |
Exceptions |
Description |
|
AbstractMethodError |
Error that occurs when a program attempts to call an abstract method. |
java.lang |
Runtime exceptions. |
|
ClassFormatError |
Error that occurs when the Java Virtual Machine attempts to read a class file and determines that the file cannot be interpreted as a class file. |
java.io |
System input and output exceptions. |
|
InstantiationError |
Error that occurs when a program tries to use the Java new construct to instantiate an abstract or interface class. |
java.awt |
User interface exceptions. |
|
InternalError |
Unexpected internal error in the Java Virtual Machine. |
java.security |
Security framework exceptions. |
|
LinkageError |
LinkageError subclasses indicate that a class has some dependency on another class. |
java.sql |
Database exceptions. |
|
VirtualMachineError |
Error that occurs when the Java Virtual Machine cannot continue to operate because it’s broken or has run out of necessary resources. |
java.naming |
Name service and directories exceptions. |
|
VerifyError |
Error that occurs when the "verifier" detects that a class file has a security problem or contains some sort of internal inconsistency. |
java.net |
Networking exceptions. |
|
UnknownError |
Unknown but serious exception in the Java Virtual Machine. |
|
|
|
StackOverflowError |
Stack overflow error has occurred because a program recurses too deeply. |
|
|
|
OutOfMemoryError |
The Java Virtual Machine cannot allocate an object because it’s out of memory. |
|
|
|
AWTError |
AWT error has occurred. |
|
|
In addition to the try, catch, throw, and finally constructs, the Java language has a large collection of exception classes. All Java exception classes, whether system-supplied or user-defined, must be derived from the Throwable class or one of its descendants. The Java exception classes are divided into two families of classes:
- Error. The family of Error class exceptions occur inside the Java Virtual Machine (JVM). Applications that encounter this family of exceptions have a difficult time recovering. These types of exceptions are not directly under the application programmer’s control. Although it’s difficult to adapt to these types of exceptions, it’s not impossible.
- Exception. The Exception classes represent the kinds of exceptions for which the application programmer can more readily develop exception handling strategies. These exception classes can be extended through in inheritance.
Let’s look at how the basic Exception classes work with no specialization. Listing 2 shows how an IOException object is created and thrown.
Listing 2 Example of basic Exception class.
void someIOProcess()
{
try{
//Do some IO processing
...
if(no_way){
IOException NotPossible = new IOException("Impossible!");
throw NotPossible;
}
...
}
catch(Exception SomeFault)
{
System.out.println(SomeFault.getMessage());
}
finally{
...
// Close IO devices
}
}
The basic Exception classes have only construction and simple reporting capabilities. They have the ability to do a simple stack trace of where they were thrown from; they don’t have the capability to correct a fault or recover from a fault that has occurred. The error message returned by the getMessage() method of the Exception classes will be determined by the string passed to the constructor for the Exception objects. In Listing 2, the string "Impossible!" passed to the constructor will be returned by the getMessage() method in the catch{} block. Also note that the finally{} block is used to close any I/O devices that were left open.