Exceptions are primarily checked exceptions, meaning that the compiler checks that your methods throw only
the exceptions they have declared themselves to throw. The standard runtime exceptions and errors extend one
of the classes RuntimeException and Error, making them unchecked exceptions. Here is the top of the
exception type hierarchy:
Checked exceptions represent conditions that, although exceptional, can reasonably be expected to occur, and
if they do occur must be dealt with in some way. Making these exceptions checked documents the existence
of the exception and ensures that the caller of a method deals with the exception in some wayor at least
consciously chooses to ignore it.
Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's
logic and cannot be reasonably recovered from at run time. For example, the
ArrayIndexOutOfBoundsException thrown when you access outside the bounds of an array tells you
that your program calculated an index incorrectly, or failed to verify a value to be used as an index. These are
errors that should be corrected in the program code. Given that you can make errors writing any statement it
would be totally impractical to have to declare or catch all the exceptions that could arise from those
errorshence they are unchecked.
The Error class, through its subclasses, defines a range of errors that indicate something has failed in the
virtual machine itself (VirtualMachineError), or in the virtual machine's attempt to execute your
application (LinkageError). These are also unchecked because they are beyond the applications ability to
control, or handle. Application code should rarely, if ever, throw these error exceptions directly.
Nearly all exceptions you create should extend Exception, making them checked exceptions. These new
checked exceptions represent the exceptional conditions that can arise in your library or application. You can
usually handle any runtime problems that arise in your code by throwing one of the existing runtime exception
classesthere are sufficient of these that one of them is usually a good match to the kind of error that has
occurred, or else the error is sufficiently general that throwing an instance of RuntimeException itself is
sufficient. Occasionally, you may want to extend an existing runtime exception class to provide additional
information about the error that occurred. Even more rarely, you might define a new class of runtime
exception that is specific to your application domain. Just remember that when it comes to unchecked
exceptions, proper usage relies on good documentation because the compiler will not be able to assist you.
Sometimes it is useful to have more data to describe the exceptional condition than what is in the
Exception class. In such cases, you can extend Exception to create a class that contains the added data
(usually set in the constructor).
For example, suppose a replaceValue method is added to the Attributed interface discussed in
Chapter 4. This method replaces the current value of a named attribute with a new value. If the named
attribute doesn't exist, an exception should be thrown, because it is reasonable to assume that one should
replace only existing attributes. That exception should contain the name of the attribute. To represent the
exception, we create the NoSuchAttributeException class: