|
|
|
 |
|
 |
An exception is always an object of some subclass of the standard class Throwable. This is true for exceptions that you define and throw yourself, as well as the standard exceptions that arise due to errors in your code. It's also true for exceptions that are thrown by methods in one or other of the standard packages.
Two direct subclasses of the class Throwable - the class Error and the class Exception - cover all the standard exceptions. Both these classes themselves have subclasses which identify specific exception conditions.
The exceptions that are defined by the class Error, and its subclasses, are characterized by the fact that they all represent conditions that you aren't expected to do anything about and, therefore, you aren't expected to catch them. There are three direct subclasses of Error - ThreadDeath, LinkageError, and VirtualMachineError. The first of these sounds the most serious, but in fact it isn't. A ThreadDeath exception is thrown whenever an executing thread is deliberately stopped, and in order for the thread to be destroyed properly you should not catch this exception. There are circumstances where you might want to - for clean-up operations for instance - in which case you must be sure to rethrow the exception to allow the thread to die. When a ThreadDeath exception is thrown and not caught, it's the thread that ends, not the program. We will deal with threads in detail in Chapter 11.
The LinkageError exception class has subclasses that record serious errors with the classes in your program. Incompatibilities between classes or attempting to create an object of a non-existent class type are the sorts of things that cause these exceptions to be thrown. The VirtualMachineError class has four subclasses that specify exceptions that will be thrown when a catastrophic failure of the Java Virtual Machine occurs. You aren't prohibited from trying to deal with these exceptions but, in general, there's little point in attempting to catch them. The exceptions that correspond to objects of classes derived from LinkageError and VirtualMachineError are all the result of catastrophic events or conditions. There is little or nothing you can do to recover from them during the execution of the program. In these sorts of situations, all you can usually do is read the error message generated by the exception, and then, particularly in the case of a LinkageError exception, try to figure out what might be wrong with your code to cause the exception to be thrown.
For almost all the exceptions that are represented by subclasses of the Exception class, you must include code in your programs to deal with them if your code may cause them to be thrown. If a method in your program has the potential to generate an exception of some such class, you must either handle the exception within the method, or register that your method may throw such an exception. If you don't, your program will not compile. We'll see in a moment how to handle exceptions and how to specify that a method can throw an exception.
One group of subclasses of Exception that are exempted from this are those derived from RuntimeException. The reason that RuntimeException exceptions are treated differently, and that the compiler allows you to ignore them, is that they generally arise because of serious errors in your code. In most situations there is little you can do to recover the situation. However, in some contexts for some of these exceptions, this is not always the case, and you may well want to include code to recognize them. There are quite a lot of subclasses of RuntimeException that are used to signal problems in various packages in the Java class library. Let's look at the exception classes that have RuntimeException as a base that are defined in the java.lang package.
The subclasses of RuntimeException defined in the standard package java.lang are:
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.
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.
| Important |
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. |
|
|
|