Section 11.3 Catching Exceptions
Subsection 11.3.1
Consider the following sample program that has an obvious divide-by-zero error. When we compile and run it, Java throws a
java.lang.ArithmeticException object.// DivideByZero.java
public class DivideByZero {
public static void main(String[] args) {
int numer = 2;
int denom = 0;
int result;
result = numer / denom;
}
DivideByZero.java with no try-catchjavac DivideByZero.java java DivideByZero Exception in thread "main" java.lang.ArithmeticException: / by zero at DivideByZero.main(DivideByZero.java:9)
To detect a thrown exception, embed all statements in a try-block. To catch exceptions thrown from code in a try-block, follow the try-block with one or more catch-blocks. Consider the following updated sample program in Listing 11.3.2, with a try-catch statement added.
// DivideByZero.java
public class DivideByZero {
public static void main(String[] args) {
int numer = 2;
int denom = 0;
int result;
try { // Try division
result = numer / denom;
} catch (ArithmeticException e) { // Catch ArithmeticException objects
System.out.println("You attempted to divide by zero.");
}
}
}
DivideByZero.java with try-catchjavac DivideByZero.java java DivideByZero You attempted to divide by zero.
The statement that performs the division was moved into a try-block, the first step required to handle exceptions. Following the try-block is a catch-block, which is followed by a pair of parentheses containing the declaration of an ArithmeticException variable. This format indicates that any exception object that can be bound to the
e variable will cause program flow to enter the catch-block. Remember, due to subtype polymorphism, we can assign any object of type class or any one of its derived classes to a variable of type class. In Listing 11.3.2, the catch-block with handle any thrown ArithmeticException objects, or objects with a type that matches any classes that derive from ArithmeticException. In this example an ArithmeticException was thrown, which matches the declaration in the catch-block, and so the message is printed.Subsection 11.3.2 Multiple Catch-blocks
You may provide multiple catch-blocks, each with different exception class variable declarations. The first declaration that can be bound to the thrown exception has the block that gets executed, if any. If a different exception object is thrown by the example above, the catch-block would not match and Java would resort to dumping the call stack. To avoid this kind of problem, it can be useful to add a final catch-block that catches all remaining exceptions by declaring the exception variable to be of class type Exception, the root of the exception class hierarchy. This way we know that all exceptions will be caught, no matter which one is thrown, because all exception objects can be bound to a variable with base class type Exception.
Consider the example in Listing 11.3.3. In
main(…) method’s nums array is initialized and then the quotient of two elements are computed in the try-block of a try-catch. The catch-block catches an ArithmeticException. The denominator is nums[0] which has a value of 0, so an ArithmeticException is certainly possible. The shell session following Listing 11.3.3 shows the result of running this program.// ExceptionTest.java
public class ExceptionTest {
public static void main(String[] args) {
int[] nums = {0, 6, 2};
int result;
try {
result = nums[3]/nums[0];
System.out.println("result: " + result);
}
catch (ArithmeticException e) {
System.out.println("You divided by 0");
}
}
}
ExceptionTest.java (version 1)javac ExceptionTest.java java ExceptionTest Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3 at ExceptionTest.main(ExceptionTest.java:8)
The output tells us that Listing 11.3.3 has another problem besides dividing by 0. It is telling us that in the expression
nums[3] the index 3 is out of bounds. Referring back to nums[] we see that indeed the array has 3 elements, and therefore the last item is at index 2. Index 3 is out of bounds.But why did we recieve an ArrayIndexOutOfBoundsException exception and not an ArithmeticException? The answer relates to how a quotient is evaluated, which is left-to-right. The numerator is evaluted before the denominator, and so the out-of-bounds index in the array is detected first. If the index was in-bounds, the ArithmeticException would have been thrown instead.
We can also catch an ArrayIndexOutOfBoundsException exception by adding another catch-statement to the try-catch. In fact, we can add as many catch-statements as we like, with the understanding that the first catch-block with a variable declaration that can be assigned to the thrown exception object is the one that will execute. But what if another type of exception is thrown, one that we have not anticipated? Rather than testing specifically for ArrayIndexOutOfBoundsException, let’s move up the Exception class hierarchy and take advantage of subtype polymorphism to catch multiple exceptions with a single catch-statement. From Figure 11.2.1 we know that all exceptions inherit Exception. Let’s update Listing 11.3.3 to catch Exception objects as well, and test our program again. See modifications in Listing 11.3.4. Note that in the catch-block we are simply printing the exception object directly. Because Exception classes override
toString() by returning a String description of the exception, the result is a reasonably informative indication of the problem that occurred.// ExceptionTest.java
public class ExceptionTest {
public static void main(String[] args) {
int[] nums = {0, 6, 2};
int result;
try {
result = nums[3]/nums[0];
System.out.println("result: " + result);
}
catch (ArithmeticException e) {
System.out.println("You divided by 0");
}
catch (Exception e) { // Catch Exception objects
System.out.println(e); // Something else happened
}
}
}
ExceptionTest.java (version 2)javac ExceptionTest.java java ExceptionTest java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3
Output from running Listing 11.3.4 tells us the class of the exception that was caught and a description of the problem.
Subsection 11.3.3 The Finally Block
The optional last part of a try-catch statement is the finally block. You may add one finally to end of a try-catch, or leave it out entirely. Unlike an "else" in a multi-branch if-statement or a "default" in a switch-statement, the "finally" of a try-catch statement always executes, regardless of whether or not an exception was thrown in the try-block, or even if a thrown exception was caught. The finally-block always executes.
Typically, a finally-block is used for cleanup tasks that must occur regardless of whether or not your code executed successfully. Cleanup tasks take the form of closing open files or open network and database connections. Depending on the resource being accessed, failing to clean up can lead to what’s know as a resource leak because leaving a resource open without properly closing it can make it unusable by others. Anything that must be done at the end of a try-catch statement may be placed in a finally-block, and Java will guarantee that it is executed.
Let’s add a finally-block to Listing 11.3.4 and test our new program, both with a statement that throws an exception and with a statement that succeeds.
// ExceptionTest.java
public class ExceptionTest {
public static void main(String[] args) {
int[] nums = {0, 6, 2};
int result;
try {
result = nums[3]/nums[0]; // Throws exception
//result = nums[1]/nums[2]; // Does not throw exception
System.out.println("result: " + result);
}
catch (ArithmeticException e) {
System.out.println("You divided by 0");
}
catch (Exception e) { // Catch Exception objects
System.out.println(e); // Something else happened
}
finally { // Time to clean up
System.out.println("Cleaning up...");
}
}
}
ExceptionTest.java (version 3)javac ExceptionTest.java java ExceptionTest java.lang.ArrayIndexOutOfBoundsException: Index 3 out of bounds for length 3 Cleaning up...
The output from Listing 11.3.5 above demonstrates that in spite of the exception being thrown, the finally-block is executed.
Let’s comment the line that throws the exception, uncomment the line that succeeds, and repeat the test.
//result = nums[3]/nums[0]; // Throws exception
result = nums[1]/nums[2]; // Does not throw exception
javac ExceptionTest.java java ExceptionTest result: 3 Cleaning up...
The expression evaluates successfully, prints a result of 3, and still the finally-block is executed.
Subsection 11.3.4 Checked vs. Unchecked Exceptions
At the bottom of the two main branches of the Exception class hierarchy in Figure 11.2.1 you will find the two labels (checked exceptions) and (unchecked exceptions). The right branch, including RuntimeException and all its derived classes are considered unchecked exception classes. This means that if a block of code has the potential to throw one of these exception classes, it is not necessary to catch the exception. Java does not check that these exceptions are thrown. On the other hand, classes under the left branch, that is, derived classes of Exception but not RuntimeException or one of its derived classes, are considered checked exceptions. If a block of code has the potential to throw a checked exception, including IOException or one of its derived classes such as FileNotFoundException, then either the code must be placed in a try-block or the exception may be deferred by indicating that the exception is thrown by modifying the method using a throws keyword and the exception class name. In either case, the exception must be caught somewhere in your program.
In the next section we will discuss reading and writing files using Java. Related classes have the potential to throw IOExceptions, which are checked exceptions, therefore most of what we do must be placed in a try-block.
