Exception Handling: A Deeper Look - Java: How to Program Early Objects - page 449

Multi- catch
It's relatively common for a try block to be followed by several catch blocks to handle
various types of exceptions. If the bodies of several catch blocks are identical, you can use
the multi- catch feature (introduced in Java SE 7) to catch those exception types in a single
catch handler and perform the same task. The syntax for a multi- catch is:
catch ( Ty p e 1 | Ty p e 2 | Ty p e 3 e)
Each exception type is separated from the next with a vertical bar ( | ). The preceding line
of code indicates that any of the types (or their subclasses) can be caught in the exception
handler. Any number of Throwable types can be specified in a multi- catch .
Uncaught Exceptions
An uncaught exception is one for which there are no matching catch blocks. You saw un-
caught exceptions in the second and third outputs of Fig. 11.2. Recall that when excep-
tions occurred in that example, the application terminated early (after displaying the
exception's stack trace ). This does not always occur as a result of uncaught exceptions. Java
uses a “multithreaded” model of program execution—each thread is a concurrent activity .
One program can have many threads. If a program has only one thread, an uncaught ex-
ception will cause the program to terminate. If a program has multiple threads, an un-
caught exception will terminate only the thread in which the exception occurred. In such
programs, however, certain threads may rely on others, and if one thread terminates due
to an uncaught exception, there may be adverse effects on the rest of the program.
Chapter 23, Concurrency, discusses these issues in depth.
Termination Model of Exception Handling
If an exception occurs in a try block (such as an InputMismatchException being thrown
as a result of the code at line 25 of Fig. 11.3), the try block terminates immediately and
program control transfers to the first of the following catch blocks in which the exception
parameter's type matches the thrown exception's type. In Fig. 11.3, the first catch block
catches InputMismatchException s (which occur if invalid input is entered) and the sec-
ond catch block catches ArithmeticException s (which occur if an attempt is made to di-
vide by zero). After the exception is handled, program control does not return to the throw
point, because the try block has expired (and its local variables have been lost ). Rather, con-
trol resumes after the last catch block. This is known as the termination model of excep-
tion handling . Some languages use the resumption model of exception handling , in
which, after an exception is handled, control resumes just after the throw point .
Notice that we name our exception parameters ( inputMismatchException and
arithmeticException ) based on their type. Java programmers often simply use the letter
e as the name of their exception parameters.
After executing a catch block, this program's flow of control proceeds to the first
statement after the last catch block (line 48 in this case). The condition in the do … while
statement is true (variable continueLoop contains its initial value of true ), so control
returns to the beginning of the loop and the user is again prompted for input. This control
statement will loop until valid input is entered. At that point, program control reaches line
32, which assigns false to variable continueLoop . The try block then terminates . If no
exceptions are thrown in the try block, the catch blocks are skipped and control continues
with the first statement after the catch blocks (we'll learn about another possibility when