|
|
|
|
Sponsored Link •
|
|
Advertisement
|
Summary
This tutorial covers the nuts and bolts of what exceptions are and how they work in the Java language and virtual machine. It discusses exception classes and objects, throwing and catching exceptions, the method invocation stack, thethrowsclause, checked vs. unchecked exceptions, andfinallyclauses.
Exceptions are the customary way in Java to indicate to a calling method that an abnormal condition has occurred. This article is a companion piece to this month's Design Techniques installment, which discusses how to use exceptions appropriately in your programs and designs. Look to this companion article for a tutorial on the nuts and bolts of what exceptions are and how they work in the Java language and virtual machine.
When a method encounters an abnormal condition (an exception condition) that it can't handle itself, it may throw an exception. Throwing an exception is like throwing a beeping, flashing red ball to indicate there is a problem that can't be handled where it occurred. Somewhere, you hope, this ball will be caught and the problem will be dealt with. Exceptions are caught by handlers positioned along the thread's method invocation stack. If the calling method isn't prepared to catch the exception, it throws the exception up to its calling method, and so on. If one of the threads of your program throws an exception that isn't caught by any method along the method invocation stack, that thread will expire. When you program in Java, you must position catchers (the exception handlers) strategically, so your program will catch and handle all exceptions from which you want your program to recover.
Exception classes
In Java, exceptions are objects. When you throw an exception, you
throw an object. You can't throw just any object as an exception,
however -- only those objects whose classes descend from
Throwable. Throwable serves as the base
class for an entire family of classes, declared in
java.lang, that your program can instantiate and
throw. A small part of this family is shown in Figure 1.
As you can see in Figure 1, Throwable has two
direct subclasses, Exception and Error.
Exceptions (members of the Exception family) are
thrown to signal abnormal conditions that can often be handled by
some catcher, though it's possible they may not be caught and
therefore could result in a dead thread. Errors (members of the
Error family) are usually thrown for more serious
problems, such as OutOfMemoryError, that may not be
so easy to handle. In general, code you write should throw only
exceptions, not errors. Errors are usually thrown by the methods
of the Java API, or by the Java virtual machine itself.
 Figure 1. A partial view of the Throwable family
|
In addition to throwing objects whose classes are declared in
java.lang, you can throw objects of your own design.
To create your own class of throwable objects, you need only
declare it as a subclass of some member of the
Throwable family. In general, however, the throwable
classes you define should extend class Exception.
They should be "exceptions." The reasoning behind this rule will
be explained later in this article.
Whether you use an existing exception class from
java.lang or create one of your own depends upon the
situation. In some cases, a class from java.lang
will do just fine. For example, if one of your methods is invoked
with an invalid argument, you could throw
IllegalArgumentException, a subclass of
RuntimeException in java.lang.
Other times, however, you will want to convey more information
about the abnormal condition than a class from
java.lang will allow. Usually, the class of the
exception object itself indicates the type of abnormal condition
that was encountered. For example, if a thrown exception object
has class IllegalArgumentException, that indicates
someone passed an illegal argument to a method. Sometimes you
will want to indicate that a method encountered an abnormal
condition that isn't represented by a class in the
Throwable family of java.lang.
As an example, imagine you are writing a Java program that simulates a customer of a virtual café drinking a cup of coffee. Consider the exceptional conditions that might occur while the customer sips. The class hierarchy of exceptions shown in Figure 2 represents a few possibilities.
 Figure 2. Exception hierarchy for coffee sipping |
If the customer discovers, with dismay, that the coffee is
cold, your program could throw a TooColdException.
On the other hand, if the customer discovers that the coffee is
overly hot, your program could throw a
TooHotException. These conditions could be
exceptions because they are (hopefully) not the normal
situation in your café. (Exceptional conditions are not
necessarily rare, just outside the normal flow of events.) The
code for your new exception classes might look like this:
// In Source Packet in file except/ex1/TemperatureException.java
class TemperatureException extends Exception {
}
// In Source Packet in file except/ex1/TooColdException.java
class TooColdException extends TemperatureException {
}
// In Source Packet in file except/ex1/TooHotException.java
class TooHotException extends TemperatureException {
}
This family of classes, the TemperatureException
family, declares three new types of exceptions for your program
to throw. Note that each exception indicates by its class the
kind of abnormal condition that would cause it to be thrown:
TemperatureException indicates some kind of problem
with temperature; TooColdException indicates
something was too cold; and TooHotException
indicates something was too hot. Note also that
TemperatureException extends Exception
-- not Throwable, Error, or any other
class declared in java.lang.
Throwing
exceptions
To throw an exception, you simply use the throw
keyword with an object reference, as in:
throw new TooColdException();
The type of the reference must be Throwable or
one of its subclasses.
The following code shows how a class that represents the
customer, class VirtualPerson, might throw
exceptions if the coffee didn't meet the customer's temperature
preferences. Note that Java also has a throws
keyword in addition to the throw keyword. Only
throw can be used to throw an exception. The meaning
of throws will be explained later in this
article.
// In Source Packet in file except/ex1/VirtualPerson.java
class VirtualPerson {
private static final int tooCold = 65;
private static final int tooHot = 85;
public void drinkCoffee(CoffeeCup cup) throws
TooColdException, TooHotException {
int temperature = cup.getTemperature();
if (temperature <= tooCold) {
throw new TooColdException();
}
else if (temperature >= tooHot) {
throw new TooHotException();
}
//...
}
//...
}
// In Source Packet in file except/ex1/CoffeeCup.java
class CoffeeCup {
// 75 degrees Celsius: the best temperature for coffee
private int temperature = 75;
public void setTemperature(int val) {
temperature = val;
}
public int getTemperature() {
return temperature;
}
//...
}
Catching
exceptions
To catch an exception in Java, you write a try block
with one or more catch clauses. Each
catch clause specifies one exception type that it is
prepared to handle. The try block places a fence
around a bit of code that is under the watchful eye of the
associated catchers. If the bit of code delimited by the
try block throws an exception, the associated
catch clauses will be examined by the Java virtual
machine. If the virtual machine finds a catch clause
that is prepared to handle the thrown exception, the program
continues execution starting with the first statement of that
catch clause.
As an example, consider a program that requires one argument
on the command line, a string that can be parsed into an integer.
When you have a String and want an int,
you can invoke the parseInt() method of the
Integer class. If the string you pass represents an
integer, parseInt() will return the value. If the
string doesn't represent an integer, parseInt()
throws NumberFormatException. Here is how you might
parse an int from a command-line argument:
// In Source Packet in file except/ex1/Example1.java
class Example1 {
public static void main(String[] args) {
int temperature = 0;
if (args.length > 0) {
try {
temperature = Integer.parseInt(args[0]);
}
catch(NumberFormatException e) {
System.out.println(
"Must enter integer as first argument.");
return;
}
}
else {
System.out.println(
"Must enter temperature as first argument.");
return;
}
// Create a new coffee cup and set the temperature of
// its coffee.
CoffeeCup cup = new CoffeeCup();
cup.setTemperature(temperature);
// Create and serve a virtual customer.
VirtualPerson cust = new VirtualPerson();
VirtualCafe.serveCustomer(cust, cup);
}
}
Here, the invocation of parseInt() sits inside a
try block. Attached to the try block is
a catch clause that catches
NumberFormatException:
catch(NumberFormatException e) {
System.out.println(
"Must enter integer as first argument.");
return;
}
The lowercase character e is a reference to the
thrown (and caught) NumberFormatException object.
This reference could have been used inside the catch
clause, although in this case it isn't. (Examples of
catch clauses that use the reference are shown later
in this article.)
If the user types Harumph as the first argument
to the Example1 program, parseInt()
will throw a NumberFormatException exception and the
catch clause will catch it. The program will
print:
Must enter integer as first argument.
Although the above example had only one catch
clause, you can have many catch clauses associated
with a single try block. Here's an example:
// In Source Packet in file except/ex1/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup) {
try {
cust.drinkCoffee(cup);
System.out.println("Coffee is just right.");
}
catch (TooColdException e) {
System.out.println("Coffee is too cold.");
// Deal with an irate customer...
}
catch (TooHotException e) {
System.out.println("Coffee is too hot.");
// Deal with an irate customer...
}
}
}
If any code inside a try block throws an
exception, its catch clauses are examined in their
order of appearance in the source file. For example, if the
try block in the above example throws an exception,
the catch clause for TooColdException
will be examined first, then the catch clause for
TooHotException. During this examination process,
the first catch clause encountered that handles the
thrown object's class gets to "catch" the exception. The ordering
of catch-clause examination matters because it is
possible that multiple catch clauses of a
try block could handle the same exception.
catch clauses indicate the type of abnormal
condition they handle by the type of exception reference they
declare. In the example above, the catch clauses
declare exception type TooColdException and
TooHotException. Had a single catch
clause declared a TemperatureException, a thrown
TooColdException or TooHotException
still would have been caught, because
TemperatureException is the superclass of both these
classes. In the object-oriented way of thinking, a
TooColdException is a
TemperatureException, therefore, a
catch clause for TemperatureException
also will catch a thrown TooColdException. An
example of this is shown below:
// In Source Packet in file except/ex2/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup) {
try {
cust.drinkCoffee(cup);
System.out.println("Coffee is just right.");
}
catch (TemperatureException e) {
// This catches TooColdException, TooHotException,
// as well as TemperatureException.
System.out.println("Coffee is too cold or too hot.");
// Deal with an irate customer...
}
}
}
Multiple catch clauses could handle the same
exception because you may, for example, declare two
catch clauses, one for TooColdException
and another for TemperatureException. In this case,
however, you must place the catch clause for
TooColdException above the one for
TemperatureException, or the source file won't
compile. If a catch clause for
TemperatureException could be declared before a
catch clause for TooColdException, the
first catch clause would catch all
TooColdExceptions, leaving nothing for the second
catch clause to do. The second catch
clause would never be reached. The general rule is: subclass
catch clauses must precede superclass
catch clauses. Here's an example of both orders,
only one of which compiles:
// In Source Packet in file except/ex3/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup) {
try {
cust.drinkCoffee(cup);
System.out.println("Coffee is just right.");
}
catch (TemperatureException e) {
// This catches TooColdException, TooHotException,
// as well as TemperatureException.
System.out.println("Coffee is too cold or too hot.");
// Deal with an irate customer...
}
// THIS WON'T COMPILE, BECAUSE THIS catch clause
// WILL NEVER BE REACHED.
catch (TooColdException e) {
System.out.println("Coffee is too cold.");
}
}
}
// In Source Packet in file except/ex4/VirtualCafe.java
// This class compiles fine.
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup) {
try {
cust.drinkCoffee(cup);
System.out.println("Coffee is just right.");
}
catch (TooColdException e) {
System.out.println("Coffee is too cold.");
// Deal with an irate customer...
}
catch (TemperatureException e) {
// This catches TooHotException as well
// as TemperatureException.
System.out.println(
"There's temperature trouble in this coffee.");
// Deal with an irate customer...
}
}
}
Embedding information in an
exception object
When you throw an exception, you are performing a kind of
structured go-to from the place in your program where an abnormal
condition was detected to a place where it can be handled. The
Java virtual machine uses the class of the exception object you
throw to decide which catch clause, if any, should
be allowed to handle the exception. But an exception doesn't just
transfer control from one part of your program to another, it
also transmits information. Because the exception is a
full-fledged object that you can define yourself, you can embed
information about the abnormal condition in the object before you
throw it. The catch clause can then get the
information by querying the exception object directly.
The Exception class allows you to specify a
String detail message that can be retrieved by
invoking getMessage() on the exception object. When
you define an exception class of your own, you can give client
programmers the option of specifying a detail message like
this:
// In Source Packet in file except/ex5/UnusualTasteException.java
class UnusualTasteException extends Exception {
UnusualTasteException() {
}
UnusualTasteException(String msg) {
super(msg);
}
}
Given the above declaration of
UnusualTasteException, client programmers could
create an instance in one of two ways:
new UnusualTasteException()new UnusualTasteException("This coffee tastes like
tea.")A catch clause can then query the object for a
detail string, like this:
// In Source Packet in file except/ex5/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup) {
try {
cust.drinkCoffee(cup);
System.out.println("Coffee tastes just right.");
}
catch (UnusualTasteException e) {
System.out.println(
"Customer is complaining of an unusual taste.");
String s = e.getMessage();
if (s != null) {
System.out.println(s);
}
// Deal with an unhappy customer...
}
}
}
When you need to embed more information into an exception
object than you can represent with a String, you can
add data and access methods to your exception class. For example,
you could define the temperature exception classes like this:
// In Source Packet in file except/ex6/TemperatureException.java
abstract class TemperatureException extends Exception {
private int temperature; // in Celsius
public TemperatureException(int temperature) {
this.temperature = temperature;
}
public int getTemperature() {
return temperature;
}
}
// In Source Packet in file except/ex6/TooColdException.java
class TooColdException extends TemperatureException {
public TooColdException(int temperature) {
super(temperature);
}
}
// In Source Packet in file except/ex6/TooHotException.java
class TooHotException extends TemperatureException {
public TooHotException(int temperature) {
super(temperature);
}
}
Given a TemperatureException family as defined
above, catch clauses can query the exception object
to find out the precise temperature that caused the problem. The
temperature field of the exception object must be
set when the object is created, as in:
// In Source Packet in file except/ex6/VirtualPerson.java
class VirtualPerson {
private static final int tooCold = 65;
private static final int tooHot = 85;
public void drinkCoffee(CoffeeCup cup) throws
TooColdException, TooHotException {
int temperature = cup.getTemperature();
if (temperature <= tooCold) {
throw new TooColdException(temperature);
}
else if (temperature >= tooHot) {
throw new TooHotException(temperature);
}
//...
}
//...
}
Wherever the exception is caught, the catch
clause can easily determine the actual temperature of the coffee
and act accordingly, as in:
// In Source Packet in file except/ex6/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup) {
try {
cust.drinkCoffee(cup);
System.out.println("Coffee is just right.");
}
catch (TooColdException e) {
int temperature = e.getTemperature();
System.out.println("Coffee temperature is "
+ temperature + " degrees Celsius.");
if (temperature > 55 && temperature <= 65) {
System.out.println("Coffee is cooling off.");
// Add more hot coffee...
}
else if (temperature > 0 && temperature <= 55) {
System.out.println("Coffee is too cold.");
// Give customer a new cup of coffee with the
// proper temperature...
}
else if (temperature <= 0) {
System.out.println("Coffee is frozen.");
// Deal with an irate customer...
}
}
catch (TooHotException e) {
int temperature = e.getTemperature();
System.out.println("Coffee temperature is "
+ temperature + " degrees Celsius.");
if (temperature >= 85 && temperature < 100) {
System.out.println("Coffee is too hot.");
// Ask customer to let it cool a few minutes...
}
else if (temperature >= 100 && temperature < 2000) {
System.out.println(
"Both coffee and customer are steamed.");
// Deal with an irate customer...
}
else if (temperature >= 2000) {
System.out.println(
"The coffee is plasma.");
// Deal with a very irate customer...
}
}
}
}
The program could deal with the temperature problem differently depending upon the coffee's actual temperature. If the coffee is just a little cold, the program could add more hot coffee to the cup. If the coffee is so cold that the customer's lips were instantly frozen to the cup, alternative measures could be taken.
Exceptions and the method
invocation stack
Code inside a try block is in a sense surrounded by
the catch clauses associated with the
try block. When an exception is thrown, the
surrounding catch clauses are examined in inside-out
order. You can nest try blocks inside
try blocks, in effect building up more and more
layers of catch clauses that surround the code. When
a method is invoked from within a try block, the
catch clauses associated with that try
block surround the code in the invoked method as well.
If that method has try blocks and catch
clauses, they are added as inner surrounding layers. What this
means is that an exception may be thrown far up the method
invocation stack before landing in a catch clause
that can handle it.
As an example, consider the following exception classes, which are simpler versions of exceptions introduced in examples above:
// In Source Packet in file except/ex7/TemperatureException.java
class TemperatureException extends Exception {
}
// In Source Packet in file except/ex7/TooColdException.java
class TooColdException extends TemperatureException {
}
// In Source Packet in file except/ex7/TooHotException.java
class TooHotException extends TemperatureException {
}
// In Source Packet in file except/ex7/UnusualTasteException.java
class UnusualTasteException extends Exception {
}
When the drinkCoffee() method of class
VirtualPerson is invoked, it throws one of these
four exceptions, chosen at random:
// In Source Packet in file except/ex7/VirtualPerson.java
class VirtualPerson {
public void drinkCoffee(CoffeeCup cup) throws TooColdException,
TemperatureException, UnusualTasteException {
try {
int i = (int) (Math.random() * 4.0);
switch (i) {
case 0:
throw new TooHotException();
case 1:
throw new TooColdException();
case 2:
throw new UnusualTasteException();
default:
throw new TemperatureException();
}
}
catch (TooHotException e) {
System.out.println("This coffee is too hot.");
// Customer will wait until it cools to an
// acceptable temperature.
}
}
//...
}
If variable i in the drinkCoffee()
method above happens to be set to a value of 0 the switch
statement will instantiate and throw a
TooHotException. Because the switch statement itself
is enclosed within a try block that has a
catch clause for TooHotException,
execution continues at that catch clause. The
program prints out:
This coffee is too hot.
If variable i in the drinkCoffee()
method above happens to be set to the value of 1, the switch
statement will instantiate and throw a
TooColdException. When this exception is thrown, the
Java virtual machine will first check the catch
clauses of the try block that surrounds the switch
statement. In this case, however, no catch clause
matches the thrown exception.
Because the TooColdException is not caught by the
drinkCoffee() method, the Java virtual machine
throws the exception up the method invocation stack to the method
that invoked drinkCoffee(). As used here, a
method invocation stack (or call stack) is a
list of the methods that have been invoked by a thread, starting
with the first method the thread invoked and ending with the
current method. A method invocation stack shows the path of
method invocations a thread took to arrive at the current
method.
A graphical representation of the method invocation stack for
drinkCoffee() is shown in Figure 3. In this figure,
the method invocation stack is shown on the right and the
corresponding Java stack is shown on the left. The Java
stack is where methods keep their state inside the Java
virtual machine. Each method gets a stack frame (or
frame), which is pushed onto the stack when the method
is invoked and popped from the stack when the method completes.
The frame is an area in memory that contains the method's local
variables, parameters, return value, and other information needed
by the Java virtual machine to execute the method. In Figure 3,
the stack is shown growing downwards. The top of the stack is at
the bottom of the picture.
 Figure 3. The method invocation stack for drinkCoffee()
|
When a method completes by executing a return statement, or by
successfully executing the last statement in a method declared as
void, it is said to complete normally. The
Java virtual machine pops the returning method's stack frame, and
continues executing just after the method invocation in the
calling method. The calling method becomes the current
method and its stack frame becomes the current
frame.
When a method throws an exception that it doesn't catch itself, it is said to complete abruptly. Methods do not return a value when they complete abruptly, though they do pass along an exception object.
For example, when the drinkCoffee() method throws
a TooColdException, it completes abruptly. Because
the exception isn't caught by drinkCoffee(), the
Java virtual machine pops drinkCoffee()'s stack
frame. It then examines the next method up the invocation stack,
in this case the serveCustomer() method of
VirtualCafe, to see if it has a catch
clause prepared to handle the exception.
Here's the code for VirtualCafe:
// In Source Packet in file except/ex7/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup)throws TemperatureException,
UnusualTasteException {
try {
cust.drinkCoffee(cup);
}
catch (TooColdException e) {
System.out.println("This coffee is too cold.");
// Add more hot coffee...
}
}
}
The serveCustomer() method above does indeed
surround its invocation of drinkCoffee() with a
try block that has an attached catch
clause for TooColdException. So the exception stops
here. The Java virtual machine makes the
serveCustomer() method's stack frame current and
continues execution at the first statement inside the
catch clause. The program prints out:
This coffee is too cold.
If variable i in the drinkCoffee()
method above happens to be set to the value of 2, the switch
statement will instantiate and throw an
UnusualTasteException. When this exception is
thrown, the Java virtual machine will first check the
catch clauses of the try block that
surrounds the switch statement. In this case, no
catch clause matches the thrown exception. The
virtual machine will then pop drinkCoffee()'s stack
frame and examine the serveCustomer() method. But in
serveCustomer(), no catch clause
attached to the try block matches the thrown
exception either. The virtual machine will therefore pop
serveCustomer()'s stack frame and examine the next
method up the invocation stack: the main() method of
class Example7.
Here's the code for Example7:
// In Source Packet in file except/ex7/Example7.java
class Example7 {
public static void main(String[] args)
throws TemperatureException {
// Create a new coffee cup.
CoffeeCup cup = new CoffeeCup();
// Create and serve a virtual customer.
try {
VirtualPerson cust = new VirtualPerson();
VirtualCafe.serveCustomer(cust, cup);
}
catch (UnusualTasteException e) {
System.out.println("This coffee has an unusual taste.");
}
}
}
This main() method was farsighted enough to
surround its invocation of serveCustomer() with a
try block that includes a catch clause
for UnusualTasteException. Thus, the Java virtual
machine will make the main() method's stack frame
current and will continue execution at the first statement in the
catch clause. The program will print:
This coffee has an unusual taste.
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:
TemperatureException
at VirtualPerson.drinkCoffee(VirtualPerson.java:20)
at VirtualCafe.serveCustomer(VirtualCafe.java:9)
at Example7.main(Example7.java:12)
The throws
clause
As you may have guessed from the examples above, the Java
language requires that a method declare in a throws
clause the exceptions that it may throw. A method's
throws clause indicates to client programmers what
exceptions they may have to deal with when they invoke the
method.
For example, the drinkCoffee() method of class
VirtualPerson, shown below, declares three
exceptions in its throws clause:
TooColdException, TemperatureException,
and UnusualTasteException. These are the three
exceptions that the method throws but doesn't catch. The method
also may throw TooHotException, but this exception
doesn't appear in the throws clause because
drinkCoffee() catches and handles it internally.
Only exceptions that will cause a method to complete abruptly
should appear in its throws clause.
// In Source Packet in file except/ex7/VirtualPerson.java
class VirtualPerson {
public void drinkCoffee(CoffeeCup cup) throws TooColdException,
TemperatureException, UnusualTasteException {
try {
int i = (int) (Math.random() * 4.0);
switch (i) {
case 0:
throw new TooHotException();
case 1:
throw new TooColdException();
case 2:
throw new UnusualTasteException();
default:
throw new TemperatureException();
}
}
catch (TooHotException e) {
System.out.println("This coffee is too hot.");
// Customer will wait until it cools to an
// acceptable temperature.
}
}
//...
}
In the drinkCoffee() method above, each exception
declared in the throws clause is explicitly thrown
by the method via a throw statement. This is one of two ways a
method can complete abruptly. The other way is by invoking
another method that completes abruptly.
An example of this is VirtualCafe's
serveCustomer() method, shown below, that invokes
VirtualPerson's drinkCoffee() method.
The serveCustomer() method contains no throw
statements, but it does declare two exceptions in its
throws clause: TemperatureException and
UnusualTasteException. These are two of three
exceptions that may be thrown by drinkCoffee(),
which serveCustomer() invokes. The third exception,
TooColdException, doesn't appear in the
throws clause because serveCustomer()
catches and handles it internally. Only those exceptions that
will cause the serveCustomer() method to complete
abruptly appear in its throws clause.
// In Source Packet in file except/ex7/VirtualCafe.java
class VirtualCafe {
public static void serveCustomer(VirtualPerson cust,
CoffeeCup cup)throws TemperatureException,
UnusualTasteException {
try {
cust.drinkCoffee(cup);
}
catch (TooColdException e) {
System.out.println("This coffee is too cold.");
// Add more hot coffee...
}
}
}
Although a throws clause lists exceptions that
may cause a method to complete abruptly, the list is not
necessarily complete. Not everything that can be thrown by a
method need be put in a throws clause.
Checked vs. unchecked
exceptions
There are two kinds of exceptions in Java, checked and
unchecked, and only checked exceptions need appear in
throws clauses. The general rule is: Any checked
exceptions that may be thrown in a method must either be caught
or declared in the method's throws clause. Checked
exceptions are so called because both the Java compiler and the
Java virtual machine check to make sure this rule is obeyed.
Whether or not an exception is "checked" is determined by its
position in the hierarchy of throwable classes. Figure 4 shows
that some parts of the Throwable family tree contain
checked exceptions while other parts contain unchecked
exceptions. To create a new checked exception, you simply extend
another checked exception. All throwables that are subclasses of
Exception, but not subclasses of
RuntimeException are checked exceptions.
 Figure 4. Checked and unchecked throwables |
The conceptual difference between checked and unchecked
exceptions is that checked exceptions signal abnormal conditions
that you want client programmers to deal with. For instance,
because the drinkCoffee() method allocates memory
with the new operator, it could potentially complete
abruptly by throwing an OutOfMemoryError. This is
not a checked exception, because it's not a subclass of
Exception. It's a subclass of Error.
Conceptually, OutOfMemoryError isn't a checked
exception because you don't want client programmers to have to
deal directly with the fact that drinkCoffee() could
complete abruptly due to low memory.
When you place an exception in a throws clause,
it forces client programmers who invoke your method to
deal with the exception, either by catching it or by declaring it
in their own throws clause. If they don't deal with
the exception in one of these two ways, their classes won't
compile. For example, because the drinkCoffee()
method declares three exceptions in its throws
clause, the serveCustomer() method, which invokes
drinkCoffee(), has to deal with those three
exceptions. In this case, serveCustomer() catches
one exception, TooColdException, but not the other
two. If serveCustomer() hadn't declared in its
throws clause the other two exceptions,
TemperatureException and
UnusualTasteException, the VirtualCafe
class would not have compiled.
Most unchecked throwables declared in java.lang
(subclasses of Error and
RuntimeException) are problems that would be
detected by the Java virtual machine. Errors usually signal
abnormal conditions that you wouldn't want a program to handle.
Problems with linking, such as NoClassDefFoundError,
or memory, such as StackOverflowError, could happen
just about anywhere in a program. In the rare cases in which they
happen, it is usually reasonable that the thread terminate.
Although most runtime exceptions (members of the
RuntimeException family) also are thrown by the Java
virtual machine itself, they usually are more an indication of
software bugs. Problems with arrays, such as
ArrayIndexOutOfBoundsException, or passed
parameters, such as IllegalArgumentException, also
could happen just about anywhere in a program. When exceptions
like these are thrown, you'll want to fix the bugs that caused
them to be thrown. You won't, however, want to force client
programmers to wrap every invocation of a method that uses arrays
with a catch clause for
ArrayIndexOutOfBoundsException.
You can throw and catch unchecked exceptions just like checked
exceptions, but the Java Language Specification advises against
throwing errors. It is intended that errors be thrown only by the
Java runtime. You may, however, reasonably throw runtime
exceptions. You can throw a runtime exception declared in
java.lang or declare your own subclasses of
RuntimeException.
To decide whether to throw a checked exception or an unchecked
runtime exception, you must look at the abnormal condition you
are signalling. If you are throwing an exception to indicate an
improper use of your class, you are signalling a software bug.
The class of exception you throw probably should descend from
RuntimeException, which will make it unchecked.
Otherwise, if you are throwing an exception to indicate not a
software bug but an abnormal condition that client programmers
should deal with every time they use your method, your exception
should be checked.
The finally
clause
Once a Java virtual machine has begun to execute a block of code
-- the statements between two matching curly braces -- it can
exit that block in any of several ways. It could, for example,
simply execute past the closing curly brace. It could encounter a
break, continue, or return
statement that causes it to jump out of the block from somewhere
in the middle. Or, if an exception is thrown that isn't caught
inside the block, it could exit the block while searching for a
catch clause.
Given that a block can be exited in many ways, it is important
to be able to ensure that something happens upon exiting a block,
no matter how the block is exited. For example, if you open a
file in a method, you may want to ensure the file gets closed no
matter how the method completes. In Java, you express such a
desire with a finally clause.
To use a finally clause, you simply: (1) Enclose
the code that has multiple exit points in a try
block; and (2) place the code that must be executed when the
try block is exited in a finally
clause.
Here's an example:
try {
// Block of code with multiple exit points
}
finally {
// Block of code that must always be executed when the try block
// is exited, no matter how the try block is exited
}
At least one clause, either catch or
finally, must be associated with each
try block. If you have both catch
clauses and a finally clause with the same
try block, you must put the finally
clause after all the catch clauses, as in:
// In Source Packet in file except/ex8/VirtualPerson.java
class VirtualPerson {
public void drinkCoffee(CoffeeCup cup) {
try {
int i = (int) (Math.random() * 4.0);
switch (i) {
case 0:
throw new TooHotException();
case 1:
throw new TooColdException();
case 2:
throw new UnusualTasteException();
default:
System.out.println("This coffee is great!");
}
}
catch (TooHotException e) {
System.out.println("This coffee is too hot.");
}
catch (TooColdException e) {
System.out.println("This coffee is too cold.");
}
catch (UnusualTasteException e) {
System.out.println("This coffee is too strong.");
}
finally {
System.out.println("Can I please have another cup?");
}
}
//...
}
If during execution of the code within a try
block, an exception is thrown that is handled by a
catch clause associated with the try
block, the finally clause will be executed after the
catch clause. For example, if a
TooColdException exception is thrown during
execution of the try block above, the program would
print the following:
This coffee is too cold. Can I please have another cup?
If an exception is thrown that is not handled by a
catch clause associated with the try block, the
finally clause is still executed. The Java virtual
machine will execute the code of the finally clause before it
continues searching elsewhere for an appropriate catch clause.
There is no way to leave a try block without
executing the code of its finally clause.
You can do anything inside a finally clause that
you can do elsewhere, including executing break, continue, or
return statements, or throwing exceptions. Such actions inside a
finally clause, however, can have some surprising
effects. For example, consider a finally clause that
is entered because of an uncaught exception. If the
finally clause executes a return, the method would
complete normally via the return, not abruptly by throwing the
exception. The exception would have in effect been handled by the
finally clause instead of a catch
clause.
As another example, consider a finally clause
that is entered because a return true; statement was
executed inside the try block. If the
finally clause executes a return false;
statement, the method will return false.
Conclusion
Java goes to great lengths to help you deal with error
conditions. Java's exception mechanisms give you a structured way
to perform a go-to from the place where an error occurs to the
code that knows how to handle the error. These mechanisms also
enable you to force client programmers (those who use
your code by calling your methods) to deal with the possibility
of an error condition encountered by your code. But Java's
mechanisms do not force you to design your programs to take
advantage of these capabilities. In the end, if you want your
programs to handle error conditions in a structured, methodical
way, you must use the exception mechanisms correctly.
For advice on how to put the exception mechanisms described in this article to use in your programs and designs, see this month's Design Techniques column, "Designing with exceptions."
About the author
Bill Venners has been writing software professionally for 12
years. Based in Silicon Valley, he provides software consulting
and training
services under the name Artima
Software Company. Over the years he has developed software
for the consumer electronics, education, semiconductor, and life
insurance industries. He has programmed in many languages on many
platforms: assembly language on various microprocessors, C on
Unix, C++ on Windows, Java on the Web. He is author of the book:
Inside
the Java Virtual Machine, published by McGraw-Hill.
Reach Bill at bv@artima.com.
This article was first published under the name Exceptions in Java in JavaWorld, a division of Web Publishing, Inc., June 1998.
|
Sponsored Links
|
