In the UnusualTasteException case, both drinkCoffee() and serveCoffee() methods completed abruptly. The Java virtual machine popped two frames from the Java stack, stopping its popping only when it reached the main() method.
The last case in this example occurs if the variable i in the drinkCoffee() method gets set to a value greater than 2. In this case, the switch statement will instantiate and throw a TemperatureException. When this exception is thrown, the Java virtual machine will go through its usual procedure of examining methods for catch clauses and popping frames for methods that can't handle the exception. The virtual machine will examine drinkCoffee(), pop its frame, examine serveCustomer(), pop its frame, examine main(), and pop its frame. At this point, however, the virtual machine has run out of frames. It can't go any further up the method invocation stack because main() was the first method invoked by the thread.
Because none of the methods on the invocation stack is prepared to handle the TemperatureException, the exception is "uncaught." It will be handled by a default handler and result in the death of the thread. Because this is the main thread of the Example7 application and the application didn't fire off any other threads that are still running when the main thread dies, the application terminates. (A dead thread doesn't always cause the death of its application, only when a dying thread is the last "non-daemon" thread running inside the application.) In most Java runtime environments, the default handler for an uncaught exception will print out a stack trace when a thread dies. For example, the java program from JDK 1.1.1 prints the following when the main thread of Example7 dies due to an uncaught TemperatureException: Continued
