exception.
12.2.1. Transfer of Control
When an exception is thrown, the statement or expression that caused the exception is said to complete
abruptly. This abrupt completion of statements causes the call chain to gradually unwind as each block or
method invocation completes abruptly until the exception is caught. If the exception is not caught, the thread
of execution terminates, after giving the thread's UncaughtExceptionHandler a chance to handle the
exceptionsee "Threads and Exceptions" on page 379.
Once an exception occurs, actions after the point at which the exception occurred do not take place. If
evaluation of a left-operand causes an exception then no part of the right-operand is evaluated; if evaluation of
a left argument expression results in an exception, then no argument to the right is evaluated. The next action
to occur will be in either a finally block, or a catch block that catches the exception.
12.2.2. Asynchronous Exceptions
A tHRow statement results in a synchronous exception, as does, say, a divide-by-zero arithmetic exceptionthe
exception occurs directly as a result of executing a particular instruction; either the throw or dividing by
zero. In contrast an asynchronous exception is one that can occur at any time, regardless of the instructions
being executed.
Asynchronous exceptions can occur in only two specific ways. The first is an internal error in the Java virtual
machinesuch exceptions are considered asynchronous because they are caused by the execution of instructions
in the virtual machine, not the instructions of the program. Needless to say, there is little that you can do about
an internal error.
The second mechanism is the use of the deprecated Thread.stop methods, or the related, and not
deprecated, stopThread methods of the JVM™ Tool Interface (JVMTI)a native code interface to the virtual
machine that allows for the inspection, and control of, a running application. These methods allow an
asynchronous exception of any kind (checked or unchecked) to be thrown at any point during the execution of
the target thread. Such a mechanism is inherently dangerous, which is why it has been deprecated in the
THRead classwe discuss this further in Chapter 14.
12.3. The tHRows Clause
The definition of the replaceValue method declares which checked exceptions it throws. The language
requires such a declaration because programmers invoking a method need to know the exceptions it can throw
just as much as they need to know its normal behavior. The checked exceptions that a method throws are as
important as the type of value it returns. Both must be declared.
The checked exceptions a method can throw are declared with a tHRows clause, which declares a
comma-separated list of exception types. Only those exceptions that are not caught within the method must be
listed.
You can throw checked exceptions that are extensions of any type of exception in the throws clause because
you can use a class polymorphically anywhere its superclass is expected. A method can throw many classes of
checked exceptionsall of them extensions of a particular exception classand declare only the superclass in the
throws clause. By doing so, however, you hide potentially useful information from programmers invoking
the method: They won't know which of the possible extended exception types could be thrown. For
documentation purposes, the tHRows clause should be as complete and specific as possible.