Start Concurrent: A Gentle Introduction to Concurrent Programming

A robust program should deal with as many errors as possible. One strategy is to have every method give back a special error code corresponding to an error when it occurs. Then, the code calling the method can react appropriately. Of course, many methods do not return a numerical type, limiting this kind of error handling. A solution that was very common in the C language, particularly in Unix system calls, was to set a globally visible int variable called errno to a value corresponding to the error that has just happened.

These approaches have a number of drawbacks. In the case of errno, if a number of different threads were running at the same time, different errors could occur simultaneously, but only one value could be kept in errno. For any system that relies on checking for an error condition after each method call, a large amount of error handling code must be mixed in with normal code. Doing so reduces code readability and makes it difficult to handle errors in a central place. Likewise, a numerical value doesn’t describe the error, requiring good documentation to know what the number means.

Java adopts a different error handling strategy called exceptions. Whenever a specified error state or unusual situation is reached, an exception is thrown. When an exception is thrown, normal execution stops immediately. The JVM starts backtracking, looking for code that’s designed to deal with that specific exception. The code that will handle the exception can be in the current method, in the calling method, in the caller of the calling method, or arbitrarily far back in the chain of method calls, all the way to main(). Each method will return, looking for code to handle this exception, until it’s found. If no handling code is found, the exception will propagate all the way past main(), and the program will end.

Exceptions give a unified and simple way to handle all errors. You can choose to deal with errors directly or delegate that responsibility to methods that call the code you’ve written. Selection statements and loops are forms of local control flow, but exceptions give us the power of non-local control flow, able to jump back through any number of method calls.

By now you’ve probably experienced a NullPointerException in the process of coding. This exception happens when an object reference is null but we try to access one of its methods or fields.

In this case, the exception is thrown by the JVM itself. It is possible to catch this exception and deal with it, but a NullPointerException generally means a mistake in the program, not an error that can be recovered from. Although many useful exceptions such as NullPointerException, ArithmeticException, and ArrayIndexOutOfBoundsException are implicitly thrown by the JVM, we’re also allowed to throw them explicitly.

Like any other object, we use the new keyword to instantiate a NullPointerException using its default constructor. Once created, we use the throw keyword to cause the exception to go into effect. Any exception you throw explicitly must use the throw keyword, but the majority of exceptions thrown by your programs will either be mistakes or exceptions thrown by library code you’re calling. If you write a significant amount of library or API code, you might use throw more often.

Normal application programmers will find themselves writing code that handles exceptions much more often than code that throws them. In order to catch an exception, you must enclose the code you think is going to throw an exception in a try block. Immediately after the try block, you can list one or more catch blocks. The first catch block that matches your exception will be executed.

In this case, trying to access the length() method of a null reference will still throw a NullPointerException, but now it’ll be caught by the catch block below. The message "Surprise! A NullPointerException!" will be printed to the screen, and execution will continue normally after the catch block. Once the exception is caught, it stops trying to propagate. Of course, whatever the code was doing when the exception was thrown was abandoned immediately because it might have depended on successful execution of the code that threw the exception. Thus, the call to the System.out.println() method in the try block will never be executed.

An exception will match the first catch block with the same class or any superclass. Since Exception is the parent of RuntimeException which is the parent of NullPointerException, we could write our example with Exception instead.

In general, you should write the most specific exception class possible for your catch blocks. Otherwise, you might be catching a different exception than you planned for, preventing that exception from propagating up to an appropriate handler. For example, the following code will randomly throw either a NullPointerException or an ArithmeticException (because of a division by 0).

This code will catch either kind of exception, but it won’t tell you which you got. Instead, the correct approach is to have one catch block for each possible kind of exception.

The list of catch blocks can be arbitrarily long. You must always go from the most specific exceptions to the most general, like Exception, otherwise some exceptions could never be reached. The Java compiler enforces this requirement. The e is a reference to the exception itself, which behaves something like a parameter in a method. It’s common to use e as the identifier, but you’re allowed to call it any legal variable name. Usually, the kind of exception is all you need to know, but every exception is an object and has fields and methods. Particularly useful is the getMessage() method which can give additional information about the exception.

In contrast to the examples given above, you’ll rarely write code to catch a NullPointerException or an ArithmeticException. Both of these exceptions are called unchecked exceptions. In Chapter 6, we used the Thread.sleep() method to put the execution of our program to sleep for a short period of time. We were forced to enclose this method call in a try block with a catch block for InterruptedException.

An InterruptedException is thrown when another thread tells your thread of execution to wake up before it finishes sleeping or waiting. This exception is a checked exception, meaning that Java insists that you use a try-catch pair anytime there’s even a chance of it being thrown. Otherwise, your code won’t compile.

Checked exceptions are those exceptions that your program must plan for. Library and API code often throw checked exceptions. For example, when trying to open a file with an API call, it’s possible that no file with that name exists or that the user might not have permission to access it. A program should catch the corresponding exceptions and recover rather than crashing. Perhaps the program should prompt the user for a new name or explain that the required permission is not set.

In Chapter 6, there were no executable statements in the catch block used with the Thread.sleep() method. However, you should never write an empty catch block. Doing so allows errors to fail silently.

We’re allowed to put code that can throw a checked exception into a try-catch block, but there’s another option. Java has a catch or specify requirement, meaning that your code is required either to catch a checked exception or to specify that it has the potential for causing that exception. To specify that a method can throw certain exceptions, we use the throws keyword. Note that this is not the same as the throw keyword.

In this case, there’s no need for a try-catch block because the method announces that it has a risk of throwing an InterruptedException. Of course, any code that uses this method will have to have a try-catch block or specify that it also throws InterruptedException. A method can throw many different exceptions, and you can simply list them out after the throws keyword, separated by commas.

Almost every exception thrown in Java is a child class of Exception, RuntimeException, or Error. Any descendant of RuntimeException or Error is an unchecked exception and is exempt from the catch or specify requirement. Any direct descendant of Exception is a checked exception and must either be caught with a try-catch block or specified with the throws keyword. We say direct descendant because RuntimeException is a child of Exception, leading to the confusing situation where only those descendants of Exception which are not also descendants of RuntimeException are checked.

To deal with the situation in which an important cleanup or finalizing task must be done no matter what, the designers of Java introduced the finally keyword. A finally block comes after all the catch blocks following a try block. The code inside the finally block will be executed whether or not any exception was thrown. A finally block is often used with file I/O to close the file, which should be closed whether or not something went wrong in the process of reading it, as we’ll demonstrate in Section 20.3.2.

The finally keyword is unusually powerful. If an exception isn’t caught and propagates up another level, the finally block will be executed before propagating the exception. Even a return statement will wait for a finally block to be executed before returning, leading to the following bizarre possibility.

This method attempts to return true, but before it can finish, the finally block returns false. Only one value can be returned, and the finally block wins. You should be aware of finally blocks and their unusual semantics. Use them sparingly and only for careful cleanup operations when needed to guarantee that some event occurs.

Code in a finally block will execute no matter what unless the JVM exits or the thread in question terminates.

Exceptions are most useful when dealing with problems encountered by API code. In those cases, your code must merely catch exceptions defined by someone else; however, it’s sometimes useful to define your own exceptions. For one thing, you might write some API code yourself. Generally, you’ll want to use the standard exceptions whenever possible, but your code might generate some unusual or specific error condition that you want to communicate to a programmer, using your own exception.

Defining a new exception is surprisingly simple. All you have to do is write a class that extends Exception. Theoretically, you could extend RuntimeException or Error instead, but you typically won’t. Children of RuntimeException are intended to indicate a bug in the program, and children of Error are intended to indicate a system error.

When creating your new exception, you don’t even have to create any methods, but it’s wise to implement a default constructor and one that takes a String as an additional message.

As with all other classes, your exceptions should be named in a readable way. This exception is apparently thrown when the world ends. It’s considered good style to end the name of any exception class with Exception. An exception class is a fully fledged class. If you need to add other fields or methods to give your exception the functionality it needs, go ahead. However, the main value of an exception lies in its existence as a named error, not in any tricks it can perform.

Here we’ll give a few examples of exception handling, although exceptions are more useful in large systems with heavy API use. We’ll start with an example of a simple calculator that detects division by zero, then look at exceptions as a tool to detect array bounds problems, and end with a custom exception used with the Color class.

In conjunction with concurrency, one exception deserves special attention: InterruptedException. This exception can happen when a thread calls wait(), join(), or sleep(). It’s a checked exception, requiring either a catch block or a throws specification.

This exception is used in cases where the executing thread must wait for some event to occur or some time to pass. In extreme circumstances, another thread can interrupt the waiting thread, forcing it to continue executing before it’s done waiting. If that happens, the code in the catch block determines how the thread should recover from being awoken prematurely.

Programmers who are new to concurrency in Java are often confused or annoyed by InterruptedException, particularly since it never seems to be thrown. Although it’s thrown rarely, situations such as a system shutting down may be best dealt with by calling interrupt() on a waiting thread, causing such an exception. Although we’ll generally leave the InterruptedException catch block empty in this book, threads written for production code should always handle interruptions gracefully.