Failure to Catch Exceptions
In Java error handling is implemented with the use of throwing and catching exceptions. Exceptions are thrown when illegal events occur or unstable states of objects are formed. These exceptions are either thrown by the system or by code written into the application. The exceptions store information about the error and are returned through the call stack until they are caught in a try/catch block. If these exceptions are not caught then they will cause the JRE to shutdown, terminating the execution of the application. When exceptions are thrown the normal execution of code is disrupted, and the exception is returned up the call stack. By utilizing this system the programmer can handle errors, such as improper array access, inability to access a certain file, or improper privileges etc. with a predetermined block of code. With a properly placed catch block whenever an exception is thrown in the subsequent call stack the catch block can handle that exception.
Exception handling is a powerful tool that allows the programmer to handle errors in a predetermined way, however this can also be a problem. If an exception is caught and is not acted upon then the events that led up to the illegal action or object state will remain unreported and unresolved. This can result in one of the objects in your application existing in an illegal or insecure state. By not acting on the error messages passed on by the exception you are opening the possibility of having objects exist in a state that was never intended by the original programmer, this state possibly being insecure. Another problem that can arise is if the catch statement is too general. If the catch statement is set up to catch all classes that are subclasses of type ÒExceptionÓ then it is very possible, and likely, that the catch block will catch and handle exceptions that werenÕt originally intended to be caught. The overly general catch statement will catch any exception thrown by the subsequent call stack.[18] This includes system exceptions such as an ArrayOutOfBoundsException and any exceptions thrown by the security manager. These will all be handled in an identical manner, which is defined by the body of the catch block. If these exceptions are system thrown exceptions they should not be caught and should rightly terminate the execution of the application. Improperly catching these exceptions may cause serious side effects if the program continues to run.
One particular problem of failing to catch exceptions occurs when an exception is thrown in a constructor. Since exceptions interrupt the normal flow of code any subsequent code after the exception is thrown will be left unexecuted. This is a problem if the constructor has passed a reference to itself to another object. An example of this is found in [11]
public class CSaver {
public C c;
}
public class C extends ASuper {
public C(CSaver s) throws SomeException {
super();
s.c = this;
...
throw new SomeException();
É //more code setting up class invariants and security measures
}
}
In this example the class C leaked its ÒthisÓ variable, the object ÒsÓ of the class CSaver has a reference to this variable. If the new SomeException is caught and not properly dealt with then it is possible for CSaver to use its reference to the malformed instance of the C class. Since the exception was thrown before the final lines of the constructor the class invariants and security precautions were not executed. This means that the instance of C as stored in the CSaver class is possibly in an insecure state. Failing to properly deal with a thrown exception has introduced an insecure object into the application.