Java Reference
In-Depth Information
Dealing with Exceptions
As we discussed in the previous sections, if your code can throw exceptions other than those of type
Error or type RuntimeException , (you can take it that we generally include the subclasses when we
talk about Error and RuntimeException exceptions) you must do something about it. Whenever
you write code that can throw an exception, you have a choice. You can supply code within the method
to deal with any exception that is thrown, or you can essentially ignore it by enabling the method
containing the exception throwing code to pass it on to the code that called the method.
Let's first see how you can pass an exception on.
Specifying the Exceptions a Method Can Throw
Suppose you have a method which can throw an exception that is neither a subclass of RuntimeException
nor of Error . This could be an IOException for example, which can be thrown if your method involves
some file input or output operations. If the exception isn't caught and disposed of in the method, you must at
least declare that the exception can be thrown. But how do you do that?
You do it simply by adding a throws clause in the definition of the method. Suppose we write a
method that uses the methods from classes that support input/output that are defined in the package
java.io . You'll see in the chapters devoted to I/O operations that some of these can throw exceptions
represented by objects of classes IOException and FileNotFoundException . Neither of these are
subclasses of RuntimeException or Error , and so the possibility of an exception being thrown
needs to be declared. Since the method can't handle any exceptions it might throw, for the simple
reason that we don't know how to do it yet, it must be defined as:
double myMethod() throws IOException, FileNotFoundException {
// Detail of the method code...
}
As the fragment above illustrates, to declare that your method can throw exceptions you just put the
throws keyword after the parameter list for the method. Then add the list of classes for the exceptions
that might be thrown, separated by commas. This has a knock-on effect - if another method calls this
method, it too must take account of the exceptions this method can throw. After all, calling a method
that can throw an exception is clearly code where an exception may be thrown. The calling method
definition must either deal with the exceptions, or declare that it can throw these exceptions as well. It's
a simple choice. You either pass the buck, or decide that the buck stops here. The compiler checks for
this and your code will not compile if you don't do one or the other. The reasons for this will become
obvious when we look at the way a Java program behaves when it encounters an exception.
Handling Exceptions
If you want to deal with the exceptions where they occur, there are three kinds of code block that you
can include in a method to handle them - try , catch , and finally :
A try block encloses code that may give rise to one or more exceptions. Code that can throw
an exception that you want to catch must be in a try block.
Search WWH ::




Custom Search