Java Reference
In-Depth Information
In the normal course of events you shouldn't meet up with the last three of these. The
ArithmeticException
turns up quite easily in your programs, as does the
IndexOutOfBoundsException
. A mistake in a
for
loop limit will produce the latter. In fact there
are two subclasses of
IndexOutOfBoundsException
that specify the type of exception thrown more
precisely -
ArrayIndexOutOfBoundsException
and
StringIndexOutOfBoundsException.
A
NullPointerException
can also turn up relatively easily, as can
ArrayStoreException
,
ClassCastException
, and
IllegalArgumentException
surprisingly enough. The last three here
arise when you are using a base class variable to call methods for derived class objects. Explicit attempts
to perform an incorrect cast, or store a reference of an incorrect type or pass an argument of the wrong
type to a method will all be picked up by the compiler. These exceptions can, therefore, only arise from
using a variable of a base type to hold references to a derived class object
The
IllegalArgumentException
class is a base class for two further exception classes,
IllegalThreadStateException
and
NumberFormatException
. The former arises when you
attempt an operation that is illegal in the current thread state. The
NumberFormatException
exception is thrown by the
valueOf()
, or
decode()
method in the classes representing integers -
that is, the classes
Byte
,
Short
,
Integer
, and
Long
. The
parseXXX()
methods in these classes can
also throw this exception. The exception is thrown if the
String
object passed as an argument to the
conversion method is not a valid representation of an integer - if it contains invalid characters for
instance. In this case a special return value cannot be used, so throwing an exception is a very
convenient way to signal that the argument is invalid.
We will try out some of the
RuntimeException
exceptions later in the chapter as some of them are
so easy to generate, but let's see what other sorts of exception classes have
Exception
as a base.
Other Subclasses of Exception
For all the other classes derived from the class
Exception
, the compiler will check that you've either
handled the exception in a method where the exception may be thrown, or you've indicated that the
method can throw such an exception. If you do neither your code won't compile. We'll look more at
how we ensure the code does compile in the next two sections.
Apart from a few that have
RuntimeException
as a base, all exceptions thrown by methods in the
Java class library are of a type that you must deal with. In Chapter 8 we will be looking at input and
output where the code will be liberally sprinkled with provisions for exceptions being thrown.
We'll see later in this chapter that when you want to define your own exceptions, you
do this by subclassing the
Exception
class. Wherever your exception can be thrown
by a method, the compiler will verify either that it is caught in the method, or that the
method definition indicates that it can be thrown by the method, just as it does for the
built-in exceptions.
