System, but they may not be reproduced for publication

ret­type methName(param­list) throws except­list {
// body
}
Here, except­list is a comma­separated list of exceptions that the method might throw
outside of itself.
You might be wondering why you did not need to specify a throws clause for some of
the preceding examples, which threw exceptions outside of methods. The answer is that
exceptions that are subclasses of Error or RuntimeException don’t need to be
specified in a throws list. Java simply assumes that a method may throw one. All other
types of exceptions do need to be declared. Failure to do so causes a compile­time error.
Actually, you saw an example of a throws clause earlier in this book. As you will recall,
when performing keyboard input, you needed to add the clause
to main( ). Now you can understand why. An input statement might generate an
IOException, and at that time, we weren’t able to handle that exception. Thus, such
an exception would be thrown out of main( ) and needed to be specified as such. Now
that you know about exceptions, you can easily handle IOException.

---

Let’s look at an example that handles IOException. It creates a method called
prompt( ), which displays a prompting message and then reads a character from the
keyboard. Since input is being performed, an IOException might occur. However, the
prompt( ) method does not handle IOException itself. Instead, it uses a throws
clause, which means that the calling method must handle it. In this example, the calling
method is main( ), and it deals with the error.
On a related point, notice that IOException is fully qualified by its package name
java.io. As you will learn in 
Chapter 10
, Java’s I/O system is contained in the java.io
package. Thus, the IOException is also contained there. It would also have been
possible to import java.io and then refer to IOException directly.
THREE ADDITIONAL EXCEPTION FEATURES
Beginning with JDK 7, Java's exception handling mechanism was expanded with the
addition of three features. The first supports automatic resource management, which
automates the process of releasing a resource, such as a file, when it is no longer
needed. It is based on an expanded form of try, called the try­with­resources
statement, and it is described in 
Chapter 10
, when files are discussed. The second new
feature is called multi­catch, and the third is sometimes called final rethrow or more
precise rethrow. These two features are described here.

---

Multi­catch allows two or more exceptions to be caught by the same catch clause. As
you learned earlier, it is possible (indeed, common) for a try to be followed by two or
more catch clauses. Although each catch clause often supplies its own unique code
sequence, it is not uncommon to have situations in which two or more catch clauses
execute the same code sequence even though they catch different exceptions. Instead of
having to catch each exception type individually, you can use a single catch clause to
handle the exceptions without code duplication.
To create a multi­catch, specify a list of exceptions within a single catch clause. You do
this by separating each exception type in the list with the OR operator. Each multi­
catch parameter is implicitly final. (You can explicitly specify final, if desired, but it is
not necessary.) Because each multi­catch parameter is implicitly final, it can't be
assigned a new value.
Here is how you can use the multi­catch feature to catch both ArithmeticException
and ArrayIndexOutOfBoundsException with a single catch clause:
Here is a simple program that demonstrates the use of this multi­catch:
The program will generate an ArithmeticException when the division by zero is

---

attempted. It will generate an ArrayIndexOutOfBoundsException when the
attempt is made to access outside the bounds of chrs. Both exceptions are caught by
the single catch statement.
The more precise rethrow feature restricts the type of exceptions that can be rethrown
to only those checked exceptions that the associated try block throws, that are not
handled by a preceding catch clause, and that are a subtype or supertype of the
parameter. While this capability might not be needed often, it is now available for use.
For the final rethrow feature to be in force, the catch parameter must be effectively
final. This means that it must not be assigned a new value inside the catch block. It
can also be explicitly specified as final, but this is not necessary.
JAVA’S BUILT-IN EXCEPTIONS
Inside the standard package java.lang, Java defines several exception classes. A few
have been used by the preceding examples. The most general of these exceptions are
subclasses of the standard type RuntimeException. Since java.lang is implicitly
imported into all Java programs, many exceptions derived from RuntimeException
are automatically available. Furthermore, they need not be included in any method’s
throws list. In the language of Java, these are called unchecked exceptions because the
compiler does not check to see if a method handles or throws these exceptions. The
unchecked exceptions defined in java.lang are listed in 
Table 9­2
. 
Table 9­3
 lists those
exceptions defined by java.lang that must be included in a method’s throws list if
that method can generate one of these exceptions and does not handle it itself. These
are called checked exceptions. In addition to the exceptions in java.lang, Java defines
several other types of exceptions that relate to other packages, such as IOException
mentioned earlier.

---

Table 9­2 The Unchecked Exceptions Defined in java.lang
Table 9­3 The Checked Exceptions Defined in java.lang
Ask the Expert
Q
: I have heard that Java supports something called chained