86.

What We've Learned

In this chapter on the Orphaned Thread bug pattern we've learned the following:

• The most common symptom of this pattern is that the program will appear to freeze. Stack traces printed to standard error and standard out are another clue.

• The obvious cure is to find and fix the underlying error in the crashing thread. Prevention is a more difficult issue.

• One way to diagnose this problem is to catch the exceptions thrown in the various threads and notify the dependent threads of the problem before exiting.

• An option for handling the thrown exception would be a message notifying the user of the problem and a call to System.exit. This option doesn't allow the program to freeze and it serves as an unmistakable marker for the user. This option works when the crash occurs in the program's main thread and other threads don't manage critical resources—but it can be dangerous in other cases.

• The ideal situation is one in which tasks like saving files, filing bug reports, and unlocking shared resources could all be done in the exception handling code before calling System.exit.

• Multithreaded code is inherently nondeterministic, so its potential for errors is greater and those errors will be much harder to reproduce and identify.

• Unit tests are a great way to discover bugs in multithreaded code, as the interactions between the threads tend to occur differently than they do when a human user interacts with the program.

• Java provides abundant support for multithreaded code, including the useful ability to throw an exception in one thread without affecting the others—but this feature can cause hard-to-track bugs.

In Chapter 19, we'll look at instances of the Run-On Initialization bug pattern, in which class constructors in the definitions don't take enough arguments to properly initialize all the fields of a class.