A.7 Chapter 7: Exception handling

Chapter 7 includes five Twist in the Tale exercises.

A.7.1 Twist in the Tale 7.1

Purpose: A finally block can’t be placed before the catch blocks. A number of programmers have compared this question with placing the label default before the label case in a switch construct. Though the latter approach works, the finally and catch blocks aren’t so flexible.

Answer: d

Explanation: Options (a), (b), and (c) are incorrect because code that defines a finally block before catch blocks won’t compile.

A.7.2 Twist in the Tale 7.2

Purpose: Unhandled exceptions thrown by an inner exception handler are passed on to the outer try-catch block to handle.

Answer: a

Explanation: Options (b), (c), and (d) are incorrect. The question assumes that a text file players.txt exists on your system so that the following code won’t throw a FileNotFoundException exception:

players = new FileInputStream("players.txt");

The code defined for this question doesn’t initialize the static variable coach before executing the following code, which is bound to throw a NullPointerException:

coach.close();

The previous line of code is defined in the inner try block, which doesn’t define an exception handler for the exception NullPointerException. This exception is propagated to the outer exception-handler block. The outer exception handler catches the NullPointerException thrown by the inner try block and executes the appropriate exception handler. Hence, the code prints the following:

players.txt found
NullPointerException

A.7.3 Twist in the Tale 7.3

Purpose: To determine whether exception-handling code for errors will execute.

Answer: b

Explanation: We know that typically errors shouldn’t be handled programmatically and that they should be left for the JVM to take care of. Also, you can’t be sure that error-handling code for all the errors will execute. For example, error-handling code for StackOverFlowError may execute but (as the name suggests) may not execute for VirtualMachineError.

A.7.4 Twist in the Tale 7.4

Purpose: ClassCastException is a runtime exception. As you know, a runtime exception can be thrown only by the JVM.

Answer: b, d

Explanation: Options (a) and (c) are incorrect because the code throws ClassCast-Exception, which is a runtime exception, for the following code:

printable = (Printable)blackInk;

Option (d) is correct because neither the class BlackInk nor any of its base classes implement the interface Printable. Thus, the code that assigns blackInk to printable without an explicit cast will fail to compile.

A.7.5 Twist in the Tale 7.5

Purpose: Trying to access a nonexistent position of an array throws an ArrayIndexOutOfBoundsException. Calling a member on a null value stored in an array throws a NullPointerException.

Answer: c

Explanation: Let’s indent the assignment of the two-dimensional array oldLaptops so that it’s easier to understand the values that are assigned to it:

String[][] oldLaptops = {
                          {"Dell", "Toshiba", "Vaio"},
                           null,
                          {"IBM"},
                           new String[10]
                        };

The preceding code results in the following assignments:

oldLaptops[0] = {"Dell", "Toshiba", "Vaio"};
oldLaptops[1] = null;
oldLaptops[2] = {"IBM"};
oldLaptops[3] = new String[10];

A pictorial representation of the two-dimensional String array oldLaptops is shown in figure A.6.

Figure A.6. The array oldLaptops

As you can see, oldLaptops[3] is an array of 10 uninitialized String objects. All the members (from index position 0 to 9) of the array oldLaptops[3] are assigned a null value. The code on line 4 tries to call the method length on the first element of array oldLaptops[0], which is null, throwing a NullPointerException.