Exceptions in Detail
(Especially Inheritance)

Below is a much longer -but still not complete- list of the the first four levels in this hierarchy; indentation indicates the subclass relationship: e.g., the Error class is a subclass of Throwable (and the Throwable class itself is a subclass of Object). For an objects to be throwable (e.g., throw new ...), it must be constructed from some class in the Throwable hierarchy (either Throwable or one of its subclasses). The Throwable class itself declares two constructors (one with a message String, one without), and a few interesting methods (getMessage and various overloaded versions of printStackTrace) that are inherited in sublcasses and often called when exceptions are caught).

The top three classes in this hierarchy (the Throwable, Error, and Exception classes) are all defined in the java.lang package (which is automatically imported into every class file). Many other exceptions are also defined in this package, while others are defined elsewhere (e.g., IOException is defined in the java.iopackage; EmptyStackException is defined in the java.util) package. Many of the exceptions that we have seen are under the hierarchy: Throwable, Exception, RuntimeException.

I compiled the following list by visiting the JavaDoc pages in Sun's API and doing lots of copying and pasting. As you can imagine by the length of this list of built-in classes, exceptions are central to the Java language. Understanding how to throw and catch exceptions is intergral to understanding Java and and how to program in it.

Note that the prime reason that so many different exception classes exist is their different names. The names are used in try/catch statements to decide selectively which exceptions to catch, and how to process these exceptions differently. When we define new classes whose methods throw exceptions, we can throw any of the exception classes already written, or we might want to define new exception classes, and by throwing them signal some special failure in the ability of methods to perform their required actions.

Throwable
  Error
    AWTError
    LinkageError
     ClassCircularityError
     ClassFormatError
     ExceptionInInitializerError
     IncompatibleClassChangeError
     NoClassDefFoundError
     UnsatisfiedLinkError
     VerifyError
    ThreadDeath
    VirtualMachineError
      InternalError
      OutOfMemoryError
      StackOverflowError
      UnknownError 
  Exception
    AclNotFoundException
    ActivationException
      UnknownGroupException
      UnknownObjectException 
    AlreadyBoundException
    ApplicationException
    AWTException
    BadLocationException
    ClassNotFoundException
    CloneNotSupportedException
      ServerCloneException
    DataFormatException
    ExpandVetoException
    FontFormatException
    GeneralSecurityException
      CertificateException
      CRLException
      DigestException
      InvalidAlgorithmParameterException
      InvalidKeySpecException
      InvalidParameterSpecException
      KeyException
      KeyStoreException
      NoSuchAlgorithmException
      NoSuchProviderException
      SignatureException
      UnrecoverableKeyException 
    IllegalAccessException
    InstantiationException
    IntrospectionException
    InvalidMidiDataException
    InvocationTargetException
    IOException
      ChangedCharSetException
      CharConversionException
      EOFException
      FileNotFoundException
      InterruptedIOException
      MalformedURLException
      ObjectStreamException
      ProtocolException
      RemoteException
      SocketException
      SyncFailedException
      UnknownHostException
      UnknownServiceException
      UnsupportedEncodingException
      UTFDataFormatException
      ZipExcept
    LastOwnerException
    LineUnavailableException
    MidiUnavailableException
    MimeTypeParseException
    NamingException
      AttributeInUseException
      AttributeModificationException
      CannotProceedException
      CommunicationException
      ConfigurationException
      ContextNotEmptyException
      InsufficientResourcesException
      InterruptedNamingException
      InvalidAttributeIdentifierException
      InvalidAttributesException
      InvalidAttributeValueException
      InvalidNameException
      InvalidSearchControlsException
      InvalidSearchFilterException
      LimitExceededException
      LinkException
      NameAlreadyBoundException
      NameNotFoundException
      NamingSecurityException
      NoInitialContextException
      NoSuchAttributeException
      NotContextException
      OperationNotSupportedException
      ReferralException
      SchemaViolationException
      ServiceUnavailableException
    NoninvertibleTransformException
    NoSuchFieldException
    NoSuchMethodException
    NotBoundException
    NotOwnerException
    ParseException
    PartialResultException
    PrinterException
      PrinterAbortException
      PrinterIOException 
    PrivilegedActionException
    RemarshalException
    RuntimeException
      ArithmeticException
      ArrayStoreException
      CannotRedoException
      CannotUndoException
      ClassCastException
      CMMException
      ConcurrentModificationException
      EmptyStackException
      IllegalArgumentException
        IllegalParameterException
        IllegalThreadStateException
        NumberFormatException
      IllegalMonitorStateException
      IllegalPathStateException
      IllegalStateException
      ImagingOpException
      IndexOutOfBoundsException
      MissingResourceException
      NegativeArraySizeException
      NoSuchElementException
      NullPointerException
      ProfileDataException
      ProviderException
      RasterFormatException
      SecurityException
      SystemException
      UndeclaredThrowableException
      UnsupportedOperationException
    SQLException
      BatchUpdateException
      SQLWarning
    TooManyListenersException
    UnsupportedAudioFileException
    UnsupportedFlavorException
    UnsupportedLookAndFeelException
    UserException 
      AlreadyBound
      BadKind
      Bounds
      Bounds
      CannotProceed
      InconsistentTypeCode
      Invalid
      InvalidName
      InvalidName
      InvalidSeq
      InvalidValue
      NotEmpty
      NotFound
      PolicyError
      TypeMismatch
      UnknownUserException
      WrongTransaction

Here is a Javadoc page for the IllegalArgumentException class. Notice its package, its superclasses, and its known (to the standard Java library) subclasses.

Also notice that this class specifies two constructors (as all exception class should): one parameterless and one with a String parameter, which should have message as its parameter's name. Notice too that none of the superclasses of this class (except Throwable, which defines getMessage and various stack tracing methods), define any methods that this class inherits. The getMessage method returns String parameter (the generic name s; it should be message) used in the second constructor. So, if they define no new methods, why do all these intervening classes exist? They exist solely to form an inheritance hierarchy, whose use in Java is described below.

First a catch clause catches an exception if the thrown object is an instanceof the type that is specified in the catch clause. Thus, given the hierarchy above, the clause catch (RuntimeException re){...} will catch thrown objects constructed from the RuntimeException class, as well as any thrown objects constructed from any subclasses of RuntimeException (of which there are a huge number).

Second, the identifier re acts like a parameter variable in the block associated with the catch clause: Java initializes it to refer to the caught object. Thus, inside the block we can refer to this variable: e.g., call methods on it: re.getMessage() (whose method is defined in the Throwable class and inherited by all its subclasses). Of course, if the object thrown is an instance of RuntimeException, then the assignment of a reference to re will work by implicit upcasting. Most often, though, the variable is not used in the associated block; it is enough to know which class of exception is thrown. Typically, I name this variable in all lower-case letters, using the upper-case letters in the class name.

Sometimes we will write a catch clause specifying the IOException type, which catches EOFException objects, as well as others that cause I/O to fail (EOFException is a subclass of IOException). By specifying a type high up in the inheritance hierarchy, a catch clause can catch many different exception classes in the hierarchy.

Third, Java checks the catch clauses sequentially. Thus, if I specify

  catch (EOFException eofe){...}
  catch (IOException ioe)  {...}

Note that because of this sequentiallity, it would be "silly" to write

  catch (IOException ioe)  {...}  
  catch (EOFException eofe){...}

These three features give us precise control over how exceptions are caught and processed. Again, this control becomes necessary only in complicated applications that must accurately diagnose and safely recover from all kinds of problems.

• An unchecked exception is any class that IS A SUBCLASS of RuntimeException (as well as RuntimeException itself).
• A checked exception is any class that is NOT A SUBCLASS of RuntimeException.

So, how does the compiler treat "checked" exceptions more carefully? In one simple way: if the code in a primary method calls a secondary method that can throw a checked exception, then the primary method must catch the exception or specify that exception in the throws part of its header. If it fails to provide either of these options, the Java compiler will detect and report an error. There are no such restrictions on unchecked exceptions.

The purpose of the throws part of a method definition is to make clear to anyone calling the method what exceptional circumstances the method might detect but not be able to handle internally. These details are important to any programmer who wants to write code that calls such a method.

So why are unchecked exceptions treated differently? This is subtle question. The best answer that I have read is that these exceptions are mostly caused by programmers writing incorrect code. On the other hand, checked exceptions are caused by external conditions, beyond the control of the programmer.

For example, the IndexOutOfBoundException is an unchecked exception. Typically, if this exception is thrown, it is because the programmer has written an incorrect loop that access the array at some illegal index. There is little reason for the program to try to detect such errors and catch them, or to propagate them out of the method in which they occur to be caught by other methods. Best to have Java automatically catch such exceptions and print an error message including a stack trace, so that the programmer can try to fix the bug.

A stack trace, printed in the console window, starts with the exception message and the method name, line number, and file name where the exception was thrown. Next comes the method that called this one (and from which line number in which file). This continues until the main method is reached (and the line number it was executing and the file in which it was in). That is the last line in the trace.

In contrast, EOFException is a checked exception. When it is thrown, it is not because the programmer wrote incorrect code (we cannot even check "is there another datum in the file"; we have to commit to trying to read one and then learn of the result), it is because external conditions do not allow another value to be read from a file. So, one way to distinguish these exceptions is by the "source" of the error: whether it is internal or external to the program's code.

There are some code examples that blur this distinction. We could use the following code to add up all the values in an array int[] a.

  int sum = 0;
  for(int i=0;;i++)
    try {
      sum += a[i]
    }catch (IndexOutOfBoundsException ioobe) {break;}

Another reason for the distinction is that unchecked exceptions can occur in any statement that accesses a member of an object (NullPointerExceptions). Thus, to avoid cluttering up method definitions, such exceptions do not have to be caught or listed after throws. Certainly we can list these exceptions after throws (and I often do) to indicate that the method might be thrown, but the Java compiler does not require it.

When programmers write a new exception class in Java, it should probably be a subclass of Exception, not RuntimeExeption. This approach is very strongly advocated in the Java Language Reference Manual. In fact, although we have studied many exceptions that are subclasses of RuntimeException (because they are intimately related to the semantics of Java's language elements), most exceptions in the large list above are checked exceptions.

Download a small program that defines new checked and unchecked exceptions, and illustrates how the Java compiler treats them differently. It is stored in Exception Demonstration.

  catch (RuntimeException re)
    {
      System.out.println("Runtime exception: " + re.getMessage();
      throw re;
    }

Suppose that the class Item defines the following method

  public static Item readFromFile(TypedBufferReader tbr)
    throws EOFException, IllegalStateException

Now suppose the class Database defines a load method that wants to read all the Items from a file into a database (storing them in an array, represented by db and used). We can write this method as

  public void load () throws IOException
  {
    TypedBufferReader tbr = 
      new TypedBufferReader("Enter name of file with items")  

    for(used=0;;used++)
      try {
        if (used == db.length)
          doubleLength();
        db[used] = Item.readFromFile(tbr);
      }catch (EOFException eofe)
         {break;}
       catch {IllegalStateException ise )
         {
           System.out.println("Error reading Item in DB: "
                              + ise.getMessage());
           throw new IOException("load: Error reading file");
         }
  }

If you get stumped on any problem, go back and read the relevant part of the lecture. If you still have questions, please get help from the Instructor, a TA, or any other student.

1. In what packages are the following exceptions declared; are they categorized as checked or unchecked: ClassCastException, EOFException, IllegalArgumentException, IllegalStateException, IndexOutOfBounds, NumberFormatException, NullPointerException.

2. We declare exception classes with a one parameter constructor (String); in what class is this value actually stored as an instance variable.

3. Draw the full inheritance hierarchy exhibited by the following jumbled class definitions (along with any other Java classes that you must include to write the full hierarchy).

     public class A extends Exception {...}
     public class E extends RuntimeException {...}
     public class F extends D {...}
     public class G {...}
     public class C extends E {...}
     public class D extends A {...}
     public class B extends A {...}

   Now, using only the classes in the hierarchy above, list all the classes whose objects can be caught by the following catch parts of a try/catch statement.

     catch (A a){...}
     catch (RuntimeException re){...}
     catch (G g){...}
     catch (F f){...}

4. Do you think the following code fragment is legal (both catch clauses using the same identifier e)? Explain your answer.

     try {
       .....
     }catch (EOFException e) {...}
      catch (IOException  e) {...}

5. In the lecture we some code like the following.

     int sum = 0;
     for(int i=0;;i++)
       try {
         ...do some complicated array stuff here
         sum += a[i]
       }catch (IndexOutOfBoundsException ioobe) {break;}

   Suppose that we wrote the "complicated array stuff" code incorrectly and it accessed an array out of bounds; explain why would the code

     int sum = 0;
     for(int i=0; i<a.length; i++) {
       ...do some complicated array stuff here
       sum += a[i]
     }

   be better.