So far we have discussed the Thread class and its related classes with little attention to error conditions. One of the reasons for this is the lack of actual error conditions, because the threading system does not depend on external hardware. Classes that deal with the disk or network have to handle all possible error conditions that exist due to the failure of the hardware. Databases or the windowing system need an error system, which allows the programmer better control over the interaction between application, data structures, and user.
But what is necessary to deal with threading? Threading is a processor resource. Starting another thread means simply setting up data structures that allow the processor to run code and that configure the processor to switch between the different threads. As we discussed in Chapter 6, threading may involve the operating system; it may involve more than one processor. But in any case, the only hardware involved is the processor(s) and possibly additional memory. The synchronization system also only involves memory: there is not much that can go wrong when there is little hardware involved. We can get processor or memory errors, but these errors generally affect the entire virtual machine and not an individual thread.
The only errors that we need to be concerned with, then, are programmer errors. It is possible for the programmer accidentally to configure the threads incorrectly or to use threads or the synchronization mechanism incorrectly.
How are error conditions reported? As with any other classes provided with the Java system, the thread classes use the concept of throwing exceptions and errors. Let’s examine some of the exceptions and errors that are thrown from the threading system.
The InterruptedException is probably the most common exception condition we have encountered in this book. It indicates that the method has returned earlier than expected. While we have chosen to catch and ignore these exceptions in most of our examples, we didn’t have to: depending on the program, it may be possible to handle the exception condition. (The solution may be as simple as calling the method again.)
Let’s examine the interrupted exception conditions that we have encountered in this book:
- The join() method
The Thread class provides the
join()method, which allows a thread to wait for another thread to finish or be terminated (see Chapter 2). If this exception is thrown, it simply means that the other thread may not have finished. Thejoin()method is also overloaded with two other method signatures that allow the program to specify a timeout. If the exception is thrown with these methods, it means that neither the termination of the other thread nor the timeout condition has been satisfied.- The sleep() method
The Thread class provides the
sleep()method, which allows a thread to wait a specified time period (see Chapter 2). When this exception is thrown, it simply means that thesleep()method has slept for less than the specified amount of time.- The wait() method
The Object class provides the
wait()method, which allows a thread to wait for a notification condition (see Chapter 4). When this exception is thrown, it means that thewait()method has not received the notification. Thewait()method is also overloaded with two other method signatures that allow the program to specify a timeout. If the exception is thrown with these methods, it means that neither the notification nor the timeout condition has been satisfied.
An InterruptedException is generated via the
interrupt() method of the Thread class.