Exceptions: When Things Go Wrong

10.1 Introduction

Source: R. Morelli and R. Walde, Trinity College
This work is licensed under a Creative Commons Attribution 4.0 License.

10.2 Handling Exceptional Conditions

To introduce you to handling exceptional conditions, Figure 10.1 shows a method that computes the average of the first N integers, an admittedly contrived example. We use it mainly to illustrate the basic concepts involved in exception handling. As its precondition suggests, the avgFirstN() method expects that N will be greater than 0. If N happens to be 0, an error will occur in the expression sum/N, because you cannot divide an integer by 0.

Figure 10.1: Poor design. No attempt is made to guard against a divideby-zero error.

Traditional Error Handling

Obviously, the method in Figure 10.1 should not simply ignore the possibility that N might be 0. Figure 10.2 shows a revised version of the method, which includes code that takes action if the method’s precondition fails. Because there is no way to compute an average of 0 elements, the revised method decides to abort the program. Aborting the program appears to be a better alternative than returning 0 or some other default value (like 1) as the method’s result and thereby allowing an erroneous value to spread throughout the program. That would just compound the error.

The revised avgFirstN() method takes the traditional approach to error handling: Error-handling code is built right into the algorithm. If N happens to be 0 when avgFirstN() is called, the following output will be generated:

Java’s Default Exception Handling

To help detect and handle common runtime errors, Java’s creators incorporated an exception-handling model into the language itself. In the case of our divide-by-zero error, the Java Virtual Machine (JVM) would detect the error and abort the program. To see this, consider the program in Figure 10.3. Note that the avgFirstN() method is passed an argument of 0 in the CalcAvgTest.main(). When the JVM detects the error, it will abort the program and print the following message:

The error message describes the error and provides a trace of the method calls, from last to first, that led to the error. This trace shows that the error occurred in the CalcAverage.avgFirstN() method, which was called by the CalcAvgTest.main() method.

As this example suggests, Java’s default exception handling is able to detect and handle certain kinds of errors and exceptional conditions. In the next section, we will identify what kinds of conditions are handled by the JVM.

10.3 Java’s Exception Hierarchy

The Java class library contains a number of predefined exceptions, some of which are shown in Figure 10.4. The most general type of exception, java.lang.Exception, is located in the java.lang package, but most of its subclasses are contained in other packages. Some of the various IOException classes are contained in the java.io package, while others are contained in the java.net package. In general, exception classes are placed in the package that contains the methods that throw those exceptions. 

Each of the classes in Figure 10.4 identifies a particular type of exception, and each is a subclass of the Exception class. Obviously a subclass defines a more specific exception than its superclass. Thus, both ArrayIndexOutOfBoundsException and StringIndexOutOfBoundsException are more specific than IndexOutOfBoundsException.

Table 10.1 gives a brief summary of some of the most important exceptions. You’ve undoubtedly encountered some of these exceptions, because they are thrown by methods we have used repeatedly in programming examples. Table 10.2 summarizes the exceptions raised by some of the methods we’ve used most frequently.

SELF-STUDY EXERCISE 

EXERCISE 10.1 What type of exception would be thrown for the following statements? 

Checked and Unchecked Exceptions

Java’s exception hierarchy is divided into two types of exceptions. A checked exception is one that can be analyzed by the Java compiler. Checked exceptions are thrown by methods such as the BufferedReader.readLine() method, in which there is a substantial likelihood that something might go wrong. When the compiler encounters one of these method calls, it checks whether the program either handles or declares the exception. Compile-time checking for these exceptions is designed to reduce the number of exceptions that are not properly handled within a program. This improves the security of Java programs.

The throws Clause

The IOException, which we encountered in Chapter 4 , is a checked exception. The Java compiler knows that readLine() is a method that can throw an IOException. A method that contains an expression that might throw a checked exception must either handle the exception or declare it. Otherwise, the compiler would generate a syntax error. The simplest way to avoid such a syntax error is to declare the exception, in our case that means qualifying the method header with the expression throws IOException.

In general, any method that contains an expression that might throw a checked expression must declare the exception. However, because one method can call another method, declaring exceptions can get a little tricky. If a method calls another method that contains an expression that might throw an unchecked exception, then both methods must have a throws clause. For example, consider the following program:

In this case, the doRead() method contains a readLine() expression, which might throw an IOException. Therefore, the doRead() method must declare that it throws IOException. However, because doRead() is called by main(), the main() method must also declare the IOException.

The alternative approach would be to catch the IOException within the body of the method. We will discuss this approach in the next section.

Unchecked Exceptions

An unchecked exception is any exception belonging to a subclass of RuntimeException (Fig. 10.4). Unchecked exceptions are not checked by the compiler. The possibility that some statement or expression will lead to an ArithmeticException or NullPointerException is extremely difficult to detect at compile time. The designers of Java decided that forcing programmers to declare such exceptions would not significantly improve the correctness of Java programs.

Therefore, unchecked exceptions do not have to be handled within a program. And they do not have to be declared in a throws clause. As shown in the chapter’s early divide-by-zero exception example, unchecked exceptions are handled by Java’s default exception handlers, unless your program takes specific steps to handle them directly. In many cases leaving the handling of such exceptions up to Java may be the best course of action, as we will see Section 10.5.

The Exception Class

The java.lang.Exception class itself is very simple, consisting of just two constructor methods (Fig. 10.5). The Throwable class, from which Exception is derived, is the root class of Java’s exception and error hierarchy. It contains definitions for the getMessage() and printStackTrace() methods, which are two methods that we will use frequently in our error-handling routines.

SELF-STUDY EXERCISE

EXERCISE 10.2 Which of the following are examples of unchecked exceptions? 

10.4 Handling Exceptions Within a Program Exception Propagation: Searching for a Catch Block

This section will describe how to handle exceptions within the program rather than leaving them to be handled by the JVM.

Trying, Throwing, and Catching an Exception

In Java, errors and other abnormal conditions are handled by throwing and catching exceptions. When an error or an exceptional condition is detected, you can throw an exception as a way of signaling the abnormal condition. This is like pulling the fire alarm. When an exception is thrown, an exception handler will catch the exception and deal with it (Fig. 10.6). We will discuss try blocks, which typically are associated with catching exceptions, later in the section. 

If we go back to our avgFirstN() example, the typical way of handling this error in Java would be to throw an exception in the avgFirstN() method and catch it in the calling method. Of course, the calling method could be in the same object or it could belong to some other object. In the latter case, the detection of the error is separated from its handling. This division of labor opens up a wide range of possibilities. For example, a program could dedicate a single object to serve as the handler for all its exceptions. The object would be sort of like the program’s fire department.

To illustrate Java’s try/throw/catch mechanism, let’s revisit the CalcAvgTest program. The version shown in Figure 10.7 mimics the way Java’s default exception handler works. If the avgFirstN() method is called with an argument that is zero or negative, an IllegalArgumentException is thrown. The exception is caught by the catch clause in the CalcAvgTest.main() method.

Let’s go through this example step by step. The first thing to notice is that if the CalcAverage.avgFirstN() method has a zero or negative argument, it will throw an exception:

Note the syntax of the throw statement. It creates a new IllegalArgumentException object and passes it a message that describes the error. This message becomes part of the exception object. It can be retrieved using the getMessage() method, which is inherited from the Throwable class (Fig. 10.4).

When a throw statement is executed, the JVM interrupts the normal execution of the program and searches for an exception handler. We will describe the details of this search shortly. In this case, the exception handler is the catch clause contained in the CalcAvgTest.main() method:

When an IllegalArgumentException is thrown, the statements within this catch clause are executed. The first statement uses the getMessage() method to print a copy of the error message. The second statement uses the printStackTrace() method, which is defined in Throwable and inherited by all Exceptions, to print a trace of the method calls leading up to the exception. The last statement causes the program to terminate.

When we run this program, the following output will be generated as a result of the illegal argument error:

Thus, as in the previous example of Java’s default exception handler, our exception handler also prints out a description of the error and a trace of the method calls that led up to the error. However, in this example, we are directly handling the exception rather than leaving it up to Java’s default exception handler. Of course, this example is intended mainly for illustrative purposes. It would make little sense to write our own exception handler if it does nothing more than mimic Java’s default handler.

Finally, note that the catch clause is associated with a try block. The handling of exceptions in Java takes place in two parts: First, we try to execute some statements, which may or may not lead to an exception. These are the statements contained within the try clause:

Second, we provide one or more catch clauses to handle particular types of exceptions. In this case, we are only handling IllegalArgumentExceptions.

As we said earlier, throwing an exception is like pulling a fire alarm. The throw occurs somewhere within the scope of the try block. The “fire department” in this case is the code contained in the catch clause that immediately follows the try block. This is the exception handler for this particular exception. There’s something like a game of catch going on here: Some method within the try block throws an Exception object, which is caught and handled by the catch block located in some other object (Fig. 10.8).

Separating Error Checking from Error Handling

As we see in the CalcAvgTest example, an important difference between Java’s exception handling and more traditional approaches is that error handling can be separated from the normal flow of execution within a program. The CalcAverage.avgFirstN() method still checks for the error and it still throws IllegalArgumentException if N does not satisfy the method’s precondition. But it does not contain code for handling the exception. The exception-handling code is located in the CalcAvgTest class.

Thus, the CalcAvgTest program creates a clear separation between the normal algorithm and the exception-handling code. One advantage of this design is that the normal algorithm is uncluttered by error-handling code and, therefore, easier to read. 

Another advantage is that the program’s response to errors has been organized into one central location. By locating the exception handler in CalcAvgTest.main(), one exception handler can be used to handle other errors of that type. For example, this catch clause could handle all IllegalArgumentExceptions that get thrown in the program. Its use of printStackTrace() will identify exactly where the exception occurred. In fact, because a Java application starts in the main() method, encapsulating all of a program’s executable statements within a single try block in the main() method will effectively handle all the exceptions that occur within a program.

Syntax and Semantics of Try/Throw/Catch

A try block begins with the keyword try followed by a block of code enclosed within curly braces. A catch clause or catch block consists of the keyword catch, followed by a parameter declaration that identifies the type of Exception being caught, followed by a collection of statements The catch block enclosed within curly braces. These are the statements that handle the exception by taking appropriate action.

Once an exception is thrown, control is transferred out of the try block to an appropriate catch block. Control does not return to the try block.

The complete syntax of the try/catch statement is summarized in Figure 10.9. The try block is meant to include a statement or statements that

might throw an exception. The catch blocks—there can be one or more— are meant to handle exceptions that are thrown in the try block. A catch block will handle any exception that matches its parameter class, including subclasses of that class. The finally block clause is an optional clause that is always executed, whether an exception is thrown or not.

The statements in the try block are part of the program’s normal flow of execution. By encapsulating a group of statements within a try block, you thereby indicate that one or more exceptions may be thrown by those statements, and that you intend to catch them. In effect, you are trying a block of code with the possibility that something might go wrong.

If an exception is thrown within a try block, Java exits the block and transfers control to the first catch block that matches the particular kind of exception that was thrown. Exceptions are thrown by using the throw statement, which takes the following general form:

The keyword throw is followed by the instantiation of an object of the ExceptionClassName class. This is done the same way we instantiate any object in Java: by using the new operator and invoking one of the exception’s constructor methods. Some of the constructors take an OptionalMessageString, which is the message that gets returned by the exception’s getMessage() method.

A catch block has the following general form:

A catch block is very much like a method definition. It contains a parameter, which specifies the class of exception that is handled by that block. The ParameterName can be any valid identifier, but it is customary to use e as the catch block parameter. The parameter’s scope is limited to the catch block, and it is used to refer to the caught exception.

The ExceptionClassName must be one of the classes in Java’s exception hierarchy (see Fig. 10.4). A thrown exception will match any parameter of its own class or any of its superclasses. Thus, if an ArithmeticException is thrown, it will match both an ArithmeticException parameter and an Exception parameter, because ArithmeticException is a subclass of Exception.

Note that there can be multiple catch clauses associated with a given try block, and the order with which they are arranged is important. A thrown exception will be caught by the first catch clause it matches. Therefore, catch clauses should be arranged in order from most specific to most general (See the exception hierarchy in Figure 10.4). If a more general catch clause precedes a more specific one, it will prevent the more specific one from executing. In effect, the more specific clause will be hidden by the more general one. You might as well just not have the more specific clause at all.

To illustrate how to arrange catch clauses, suppose an ArithmeticException is thrown in the following try/catch statement:

In this case, the exception would be handled by the more specific ArithmeticException block. On the other hand, if some other kind of exception is raised, it will be caught by the second catch clause. The Exception class will match any exception that is thrown. Therefore, it should always occur last in a sequence of catch clauses.

Restrictions on the try/catch/finally Statement

There are several important restrictions that apply to Java’s exceptionhandling mechanism. We’ll describe these in more detail later in this chapter.

• A try block must be immediately followed by one or more catch clauses and a catch clause may only follow a try block. 
• A throw statement is used to throw both checked exceptions and unchecked exceptions, where unchecked exceptions are those belonging to RuntimeException or its subclasses. Unchecked exceptions need not be caught by the program. 
• A throw statement must be contained within the dynamic scope of a try block, and the type of Exception thrown must match at least one of the try block’s catch clauses. Or the throw statement must be contained within a method or constructor that has a throws clause for the type of thrown Exception.

Dynamic Versus Static Scoping

How does Java know that it should execute the catch clause in CalcAvgTest.main() when an exception is thrown in avgFirstN()? Also, doesn’t the latest version of avgFirstN() (Fig. 10.7) violate the restriction that a throw statement must occur within a try block?

An exception can only be thrown within a dynamically enclosing try block. This means that the throw statement must fall within the dynamic scope of an enclosing try block. Let’s see what this means.

Dynamic scoping refers to the way a program is executed. For example, in CalcAverage (Fig. 10.7), the avgFirstN() method is called from within the try block located in CalcAvgTest.main(). Thus, it falls within the dynamic scope of that try block.

Contrast dynamic with what you have learned about static scope, which we’ve used previously to define the scope of parameters and local variables (Fig. 10.10). Static scoping refers to the way a program is written. A statement or variable occurs within the scope of a block if its text is actually written within that block. For example, consider the definition of MyClass (Fig. 10.11). The variable X occurs within the (static) scope of method1(), and the variable Y occurs within the (static) scope of method2().

A method’s parameters and local variables occur within its static scope. Also, in the MyClass definition, the System.out.println() statements occur within the static scope of method1() and method2(), respectively. In general, static scoping refers to where a variable is declared or where a statement is located. Static scoping can be completely determined by just reading the program.

Dynamic scoping can only be determined by running the program. For example, in MyClass the order in which its statements are executed depends on the result of Math.random(). Suppose that when random() is executed it returns the value 0.99. In that case, main() will call method2(), which will call system.out.println(), which will print

“Hello2.” In that case, the statement System.out.println("Hello" + Y) has the following dynamic scope:

It occurs within the (dynamic) scope of method2(), which is within the (dynamic) scope of main(). On the other hand, if the result of random() had been 0.10, that particular println() statement wouldn’t have been executed at all. Thus, to determine the dynamic scope of a particular statement, you must trace the program’s execution. In fact, this is what the printStackTrace() method does. It prints a trace of a statement’s dynamic scope.

Exception Propagation: Searching for a Catch Block

When an exception is thrown, Java uses both static and dynamic scoping to find a catch clause to handle it. Java knows how the program is defined—after all, it compiled it. Thus, the static scope of a program’s methods is determined by the compiler. Java also places a record of every method call the program makes on a method call stack. A method call stack is a data structure that behaves like a stack of dishes in the cafeteria. For each method call, a method call block is placed on top of the stack (like a dish), and when a particular method call returns, its block is removed from the top of the stack (Fig. 10.12).

An important feature of the method call stack is that the current executing method is always represented by the top block on the method call stack. If an exception happens during that method call, you can trace backward through the method calls, if necessary, to find an exception handler for that exception. In Figure 10.12, you can visualize this backtrace as a matter of reversing the direction of the curved arrows.

In order to find a matching catch block for an exception, Java uses its knowledge of the program’s static and dynamic scope to perform a method stack trace. The basic idea is that Java traces backward through the program until it finds an appropriate catch clause. The trace begins within the block that threw the exception. Of course, one block can be nested (statically) within another block. If the exception is not caught by the block in which it is thrown, Java searches the enclosing block. This is static scoping. If it is not caught within the enclosing block, Java searches the next higher enclosing block, and so on. This is still static scoping.

If the exception is not caught at all within the method in which it was thrown, Java uses the method call stack (Fig. 10.12) to search backward through the method calls that were made leading up to the exception. This is dynamic scoping. In the case of our CalcAvgTest() example (Fig. 10.7), Java would search backward to the CalcAvgTest.main() method, which is where avgFirstN() was called, and it would find the catch clause there for handling IllegalArgumentExceptions.

SELF-STUDY EXERCISES 

EXERCISE 10.3 Suppose a program throws an ArrayIndexOutOfBoundsException. Using the exception hierarchy in Figure 10.4, determine which of the following catch clauses could handle that exception. 

EXERCISE 10.5 For the values returned by random() in the previous exercise, show what would be output if printStackTrace() were called in addition to printing an error message. 

EXERCISE 10.6 In the MyClass2 program, suppose that the first time random() is called it returns 0.44, and the second time it is called it returns 0.98. What output would be printed by the program?

EXERCISE 10.7 For the values returned by random() in the previous exercise, show what would be output if printStackTrace() were called instead of printing an error message.

EXERCISE 10.8 Find the divide-by-zero error in the following program, and then show what stack trace would be printed by the program:

EXERCISE 10.9 Modify method2() so that it handles the divide-byzero exception itself, instead of letting Java handle it. Have it print an error message and a stack trace. 

EXERCISE 10.10 What would be printed by the following code segment if someValue equals 1000?

EXERCISE 10.11 What would be printed by the code segment in the preceding question if someValue equals 50? 

EXERCISE 10.12 Write a try/catch block that throws an Exception if the value of variable X is less than zero. The exception should be an instance of Exception and, when it is caught, the message returned by getMessage() should be “ERROR: Negative value in X coordinate.”

10.5 Error Handling and Robust Program Design

An important element of program design is to develop appropriate ways of handling erroneous and exceptional conditions. As we have seen, the JVM will catch any unchecked exceptions that are not caught by the program itself. For your own (practice) programs, the best design may simply be to use Java’s default exception handling. The program will terminate when an exception is thrown, and then you can debug the error and recompile the program.

On the other hand, this strategy would be inappropriate for commercial software, which cannot be fixed by its users. A well-designed commercial program should contain exception handlers for those truly exceptional conditions that may arise.

In general there are three ways to handle an exceptional condition that isn’t already handled by Java (Table 10.3). If the exceptional condition cannot be fixed, the program should be terminated, with an appropriate error message. Second, if the exceptional condition can be fixed without invalidating the program, then it should be remedied and the program’s normal execution should be resumed. Third, if the exception cannot be fixed, but the program cannot be terminated, the exceptional condition should be reported or logged in some way, and the program should be resumed.

Print a Message and Terminate

Our illegal argument example is a clear case in which the exception is best handled by terminating the program. In this case, this particular error is best left to Java’s default exception handling, which will terminate the program when the exception is thrown. There is simply no way to satisfy the postcondition of the avgFirstN() method when N is less than or equal to 0. This type of error often calls attention to a design flaw in the program’s logic that should be caught during program development. The throwing of the exception helps identify the design flaw. 

Similar problems can (and often do) arise in connection with errors that are not caught by Java. For example, suppose that your program receives an erroneous input value, whose use would invalidate the calculation it is making. This won’t be caught by Java. But it should be caught by your program, and an appropriate alternative here is to report the error and terminate the program. Fixing this type of error may involve adding routines to validate the input data before they are used in the calculation.

In short, rather than allowing an erroneous result to propagate throughout the program, it is best to terminate the program.

Log the Error and Resume

Of course, the advice to stop the program assumes that the program can be terminated reasonably. Some programs—such as programs that monitor the space shuttle or programs that control a nuclear magnetic resonance (NMR) machine—cannot (and should not) be terminated because of such an error.

Such programs are called failsafe because they are designed to run without termination. For these programs, the exception should be reported in whatever manner is most appropriate, but the program should continue running. If the exceptional condition invalidates the program’s computations, then the exception handler should make it clear that the results are tainted.

Other programs—such as programs that analyze a large transaction database—should be designed to continue processing after catching such errors. For example, suppose a large airline runs a program once a day to analyze the ticketing transactions that took place. This kind of program might use exceptions to identify erroneous transactions or transactions that involve invalid data of some sort. Because there are bound to be many errors of this kind in the database, it is not reasonable to stop the program. This kind of program shouldn’t stop until it has finished processing all of the transactions. An appropriate action for this kind of program is to log the exceptions into some kind of file and continue processing the transactions.

Suppose a divide-by-zero error happened in one of these programs. In that case, you would override Java’s default exception handling to ensure that the program is not terminated. More generally, it’s important that these types of programs be designed to catch and report such exceptions. This type of exception handling should be built right into the program’s design.

Fix the Error and Resume

As an example of a problem that can be addressed as the program runs, consider the task of inputting an integer into a text field. As you have probably experienced, if a program is expecting an integer and you attempt to input something beside an integer, a NumberFormatException is generated and the program will terminate. For example, if you enter “$55” when prompted to input an integer dollar amount, this will generate an exception when the Integer.parseInt() method is invoked. The input string cannot be parsed into a valid int. However, this is the kind of error that can be addressed as the program is running.

Let’s design a special IntField that functions like a normal text field but accepts only integers. If the user enters a value that generates a NumberFormatException, an error message should be printed and the user should be invited to try again. As Figure 10.13 shows, we want this special field to be a subclass of JTextField and to inherit the basic JTextField functionality. It should have the same kind of constructors that a normal JTextField has. This leads to the definition shown in Figure 10.14.

Note that the constructor methods use super to call the JTextField constructor. For now, these two constructors should suffice. However, later we will introduce a third constructor that allows us to associate a bound with the IntField later in this chapter. 

Our IntField class needs a method that can return its contents. This method should work like JTextField.getText(), but it should return a valid integer. The getInt() method takes no parameters and will return an int, assuming that a valid integer is typed into the IntField. If the user enters “$55,” a NumberFormatException will be thrown by the Integer.parseInt() method. Note that getInt() declares that it throws this exception. This is not necessary because a NumberFormatException is not a checked exception, but it makes the code clearer.

Where and how should this exception be handled? The exception cannot easily be handled within the getInt() method. This method has to return an integer value. If the user types in a non-integer, there’s no way to return a valid value. Therefore, it’s better just to throw the exception to the calling method, where it can be handled more easily.

In a GUI application or applet, the calling method is likely to be an actionPerformed() method, such as the following:

The call to getInt() is embedded in a try/catch block. This leads to the design summarized in Figure 10.15. The IntField throws an exception that is caught by the GUI, which then displays an error message.

If the user inputs a valid integer, the program will just report a message that displays the value. A more real-world example would make a more significant use of the value. On the other hand, if the user types an erroneous value, the program will pop up the dialog box shown in Figure 10.16. (See the “From the Library” section of this chapter for more on dialog boxes.) When the user clicks the OK button, the program will resume normal execution, so that when an exception is raised, the enter value is not used, and no harm is done by an erroneous value. The user can try again to input a valid integer. Note that the finally clause repaints the GUI. In this case, repainting would display the appropriate message on the applet or the application.

This is an example of what we might call defensive design. Defensive design is when we anticipate a possible input error and take steps to ensure that a bad value is not propagated throughout the program.

Admittedly, the sense in which the error here is “fixed” is simply that the user’s original input is ignored and reentered. This is a legitimate and simple course of action for this particular situation. It is far preferable to ignoring the exception. If the program does not handle this exception itself, Java will catch it and will print a stack trace and terminate the program. That would not be a very user-friendly interface!

Clearly, this is the type of exceptional condition that should be anticipated during program design. If this happens to be a program designed exclusively for your own use, then this type of exception handling might be unnecessary. But if the program is meant to be used by others, it is important that the program be able to handle erroneous user input without crashing.

To Fix or Not to Fix

Let’s now consider a problem where it is less clear whether an exception can be successfully fixed “on the fly.” Suppose you have a program that contains an array of Strings, which is initially created with just two elements.

If an attempt is made to add more than two elements to the array, an ArrayIndexOutOfBoundsException will be raised. This exception can be handled by extending the size of the array and inserting the element. Then the program’s normal execution can be resumed.

To begin creating such a program, let’s first design a method that will insert a string into the array. Suppose that this is intended to be a private method that will only be used within the program. Also, let’s suppose that the program maintains a variable, count, that tracks how many values have been stored in the array. Therefore, it will not be necessary to pass the array as a parameter. So, we are creating a void method with one parameter, the String to be inserted:

The comment notes where an exception might be thrown.

Can we handle this exception? When this exception is raised, we could create a new array with one more element than the current array. We could copy the old array into the new array and then insert the String in the new location. Finally, we could set the variable list, the array reference, so that it points to the new array. Thus, we could use the following try/catch block to handle this exception:

The effect of the catch clause is to create a new array, still referred to as list, but that contains one more element than the original array.

Note the use of the finally clause here. For this problem it’s important that we incrementally count in the finally clause. This is the only way to guarantee that count is incremented exactly once whenever an element is assigned to the array. 

The design of the FixArrayBound class is shown in Figure 10.17. It provides a simple GUI interface that enables you to test the insertString() method. This program has a standard Swing interface, using a JFrame as the top-level window. The program’s components are contained within a JPanel that’s added to the JFrame in the main() method. 

Each time the user types a string into the text field, the actionPerformed() method calls the insertString() method to add the string to the array. On each user action, the JPanel is repainted. The paintComponent() method simply clears the panel and then displays the array’s elements (Fig. 10.18).

The complete implementation of FixArrayBound is given in Figure 10–19. This example illustrates how an exception can be handled successfully and the program’s normal flow of control resumed. However, the question is whether such an exception should be handled this way.

Unfortunately, this is not a well-designed program. The array’s initial size is much too small for the program’s intended use. Therefore, the fact that these exceptions arise at all is the result of poor design. In general, exceptions should not be used as a remedy for poor design.

For a program that uses an array, the size of the array should be chosen so that it can store all the objects required by the program. If the program is some kind of failsafe program, which cannot afford to crash, then something like the previous approach might be justified, provided this type of exception occurs very rarely. Even in that case it would be better to generate a message that alerts the program’s user that this condition has occurred. The alert will indicate a need to modify the program’s memory requirements and restart the program.

Figure 10.18: The strings displayed are stored in an array that is extended each time a new string is entered.

If it is not known in advance how many objects will be stored in an array, a better design would be to make use of the java.util.Vector class (see “From the Java Library” in Chapter 9). Vectors are designed to grow as new objects are inserted. In some ways the exception-handling code in our example mimics the behavior of a vector. However, the Vector class makes use of efficient algorithms for extending its size. By contrast, exception-handling code is very inefficient. Because exceptions force the system into an abnormal mode of execution, it takes considerably longer to handle an exception than it would to use a Vector for this type of application.

SELF-STUDY EXERCISE 

EXERCISE 10.13 For each of the following exceptions, determine whether it can be handled in such a way that the program can be resumed or whether the program should be terminated: 

a. A computer game program detects a problem with one of its GUI elements and throws a NullPointerException. 

b. A factory assembly-line control program determines that an important control value has become negative and generates an ArithmeticException. 

c. A company’s Web-based order form detects that its user has entered an invalid String and throws a SecurityException.

10.6 Creating and Throwing Your Own Exceptions

Like other Java classes, the Exception class can be extended to handle cases that are not already covered by Java’s built-in exceptions. Exceptions that you define will be handled the same way by the Java interpreter, but you will have to throw them yourself.

For example, Figure 10.20 shows the design of an exception that can be used for validating that an integer is less than or equal to a certain maximum value. It would be coded as follows:

The class extends Exception and consists entirely of a constructor method that calls the superclass constructor. The argument passed to the superclass constructor is the message that will be returned by getMessage() when an instance of this exception is created.

Now let’s consider an example where this new exception will be thrown. Suppose we wish to constrain the IntField class that we developed previously (Fig. 10.14) so that it will only accept numbers that are less than a certain bound. First, let’s modify IntField so that its bound can be set when an instance is created. We want its bound to be an instance variable with some initial value, and we want to provide a constructor that can be used to override the default (Fig. 10.21).

This leads to the following revision of IntField:

Our new constructor has the signature IntField(int,int), which doesn’t duplicate any of JTextField’s constructors. This is good design, because in extending a class, we want to be careful about the effect that our definitions have on the original methods in the superclass. Superclass methods should be overridden by design, not by accident. If a method is redefined inadvertently, it might not function as expected by users of the subclass.

Note how we have handled the problem of setting the default value of the bound. Integer.MAX VALUE is a class constant that sets the maximum value for the int type. It’s an appropriate value to use, because any valid int that the user types should be less than or equal to MAX VALUE. Given these changes to IntField, let’s now incorporate our new exception into its getInt() method (Fig. 10.22).

This new version of getInt() throws an exception if the integer entered by the user is greater than the IntField’s bound. Here again, it is difficult to handle this exception appropriately in this method. The method would either have to return an erroneous value—because it must return something—or it must terminate. Neither is an acceptable alternative. It is far better to throw the exception to the calling method.

The IntFieldTester class (Fig. 10.23) has the design and functionality shown in Figure 10.15. It provides a simple GUI interface to test the IntField class. It prompts the user to type an integer that is less than 100, and then it echoes the user’s input. Note how the exception is handled in the actionPerformed() method. If an exception is thrown in IntField.getInt(), the actionPerformed() method pops up an error dialog, and the erroneous input is not used. Instead, the user is given another chance to enter a valid integer.

SELF-STUDY EXERCISES 

EXERCISE 10.14 Define a new Exception named FieldIsEmptyException, which is meant to be thrown if the user forgets to enter a value into a IntField. 

EXERCISE 10.15 Modify the IntField.getInt() method so that it throws and catches the FieldIsEmptyException.

10.7 From the Java Library: JOptionPane

For example, a file dialog is opened whenever you want to open or save a file. It provides an interface that lets you name the file and helps you search through the computer’s directory structure to find a file.

A warning dialog or error dialog is opened whenever a program needs to notify or warn you that some kind of error occurred. It usually presents an error message and an OK button that you click to dismiss the dialog. 

Dialogs are easy to create and use in Java. The Swing component set provides several different kinds of basic dialogs that can be incorporated into your program with one or two lines of code. For example, the IntFieldTester class makes use of a simple message dialog to report an input error to the user. This dialog was created by the following code segment in the program (see Figure 10.23):

This method call displays the window shown in Figure 10.16. It contains the error message and an OK button that is used to close the window. The showMessageDialog() method is a static method of the javax.swing.JOptionPane class. This class provides a collection of similar methods for creating and displaying basic dialog boxes.

A dialog differs from other kinds of top-level windows—such as JApplet and JFrame—in that it is associated with another window (Fig. 10–24). The first parameter in this version of the showMessageDialog() method is a reference to the dialog’s parent window. The second parameter is a String representing the message. 

The basic message dialog used in this example is known as a modal dialog. This means that once it’s been displayed, you can’t do anything else until you click the OK button and dismiss the dialog. It’s also possible to create nonmodal dialogs. These can stay around on the screen while you move on to other tasks. 

Note that the dialog box also contains an icon that symbolizes the purpose of the message (Fig. 10.25). The icon is representative of the dialog’s message type. Among the basic types available in JOptionPane are the following:

To set the dialog to anything other than the default (informational) type, you can use the following version of showMessageDialog(): 

The first parameter is a reference to the parent window. The second is the message string. The third is a string used as the dialog window’s title, and the fourth is one of the five dialog types. For example, we can change our dialog to an error dialog with the following statement:

This would produce the dialog shown in Figure 10.25. T

he other kinds of basic dialogs provided by the JOptionPane class are listed in Table 10.4. All of the dialogs listed there can be created with a line or two of code. In addition to these, it’s also possible to create sophisticated dialogs that can be as customized as any other GUI interface you can build in Java.

In this chapter, you have learned how to handle exceptional conditions that occur in programs. You now know that Java has a default exception handler that can take of many situations, and you also understand that proper program design using Java exception-handling elements helps deal with many other situations. This chapter continues the emphasis on good program design for creating useful, stable programs.

Chapter Summary

Technical Terms 

• catch block 
• catch an exception 
• checked exception 
• dialog box 
• dynamic scope 
• error dialog 
• exception 
• exception handling 
• finally block 
• method call stack 
• method stack trace 
• modal dialog 
• static scope 
• throw an exception 
• try block 
• unchecked exception

The Try/Catch Statement 

The try/catch/finally statement has the following syntax:

The try block is meant to include a statement or statements that might throw an exception. The catch blocks—there can be one or more—are meant to handle exceptions that are thrown in the try block. A catch block will handle any exception that matches its parameter class, including subclasses of that class. The finally block is optional. It will be executed whether an exception is thrown or not. If an exception is thrown in the try block, the try block is exited permanently.

The throw statement inside the try block is there to illustrate how throw can be used. You will usually not see a throw statement in a try block, because most throws are done from within Java library methods, which are called from a try block.

Summary of Important Points

• In Java, when an error or exceptional condition occurs, you throw an Exception, which is caught by special code known as an exception handler. A throw statement—throw new Exception()—is used to throw an exception. 
• A try block is a block of statements containing one or more statements that may throw an exception. Embedding a statement in a try block indicates your awareness that it might throw an exception and your intention to handle the exception. 
• Java distinguishes between checked and unchecked exceptions. Checked exceptions must either be caught by the method in which they occur or you must declare that the method containing that statement throws the exception. 
• Unchecked exceptions are those that belong to subclasses of RuntimeException. If they are left uncaught, they will be handled by Java’s default exception handlers.
• A catch block is a block of statements that handles the exceptions that match its parameter. A catch block can only follow a try block, and there may be more than one catch block for each try block. 
• The try/catch syntax allows you to separate the normal parts of an algorithm from special code meant to handle errors and exceptional conditions. 
• A method stack trace is a trace of the method calls that have led to the execution of a particular statement in the program. The Exception.printStackTrace() method can be called by exception handlers to print a trace of exactly how the program reached the statement that threw the exception. 
• Static scoping refers to how the text of the program is arranged. If a variable is declared within a method or a block, its static scope is confined to that method or block.
• Dynamic scoping refers to how the program is executed. A statement is within the dynamic scope of a method or block if it is called from that method or block, or if it is called by some other method that was called from that method or block. 
• When searching for a catch block to handle an exception thrown by a statement, Java searches upward through the statement’s static scope and backward through its dynamic scope until it finds a matching catch block. If none is found, the Java Virtual Machine will handle the exception itself by printing an error message and a method stack trace. 
• Many Java library methods throw exceptions when an error occurs. These throw statements do not appear in the program. For example, Java’s integer division operator will throw an ArithmeticException if an attempt is made to divide by zero. 
• Generally, there are four ways to handle an exception: (1) Let Java handle it; (2) fix the problem that led to the exception and resume the program; (3) report the problem and resume the program; and (4) print an error message and terminate the program. Most erroneous conditions reported by exceptions are difficult or impossible to fix.
• A finally statement is an optional part of a try/catch block. Statements contained in a finally block will be executed whether an exception is raised or not. 
• A well-designed program should use exception handling to deal with truly exceptional conditions, not as a means of normal program control. 
• User-defined exceptions can be defined by extending the Exception class or one of its subclasses.