Java Exception Hierarchy: Throwable, Error, Exception

Why does Integer.parseInt("abc") compile without any try-catch, while NumberFormat.getInstance().parse("abc") does not — the compiler reports unreported exception java.text.ParseException; must be caught or declared to be thrown? Both methods parse a string, and both fail on bad input. The only difference is where their exceptions sit in the hierarchy: NumberFormatException extends RuntimeException, while ParseException extends Exception directly.

The Java exception hierarchy is a tree of classes rooted at java.lang.Throwable, which has two direct subclasses: Error (serious JVM failures) and Exception (problems a program can handle). A subclass of Exception, RuntimeException, groups errors in program logic. The position of a class in this tree determines whether the compiler requires you to handle the exception: checked or unchecked.

Exception class hierarchy: Throwable, Error, Exception

Every exception and error in Java inherits from the Throwable class — only its objects can be thrown with throw and caught in catch. Throwable splits into two branches, Error and Exception, and inside Exception there is a separate RuntimeException branch. These three branches are the types of exceptions in Java you meet in practice.

The same Java exception tree in text form, with the most common classes:

java.lang.Object
└── java.lang.Throwable
    ├── java.lang.Error                          unchecked
    │   └── VirtualMachineError
    │       ├── OutOfMemoryError
    │       └── StackOverflowError
    └── java.lang.Exception                      checked
        ├── java.io.IOException
        │   └── java.io.FileNotFoundException
        ├── java.text.ParseException
        ├── java.sql.SQLException
        ├── InterruptedException
        ├── ClassNotFoundException
        └── java.lang.RuntimeException           unchecked
            ├── ArithmeticException
            ├── NullPointerException
            ├── ClassCastException
            ├── IllegalStateException
            ├── IllegalArgumentException
            │   └── NumberFormatException
            └── IndexOutOfBoundsException
                └── ArrayIndexOutOfBoundsException

Errors are JVM-level failures: the heap is exhausted (OutOfMemoryError), the call stack overflows (StackOverflowError), a class cannot be found while loading (NoClassDefFoundError). Handling errors of this kind in your own program is not recommended, because your code usually cannot fix their cause: no catch block can give the JVM more memory.

Exceptions are problems that are predictable and can, in principle, be dealt with by the program: a file is missing, a string is not a number, the network is down. They are caught and handled.

RuntimeException is an important subclass of Exception. Its subclasses signal bugs in program logic: integer division by zero, an array index out of bounds, a method call on null. Such exceptions are better prevented with checks in the code than caught.

Checked vs unchecked exceptions in Java

Checked exceptions are Exception and all its subclasses except the RuntimeException branch; the compiler requires you to catch them or declare them in throws. Unchecked exceptions are RuntimeException, Error and their subclasses; the compiler does not check whether they are handled.

How to handle an exception and in which order to write several catch blocks is explained in the lesson Java Try Catch Finally. Declaring an exception in a method signature with throws and the rules for checked exceptions when overriding methods are covered in separate lessons of this module.

Example 1. Checked ParseException declared in main

The NumberFormat.parse() method declares throws ParseException, so the calling code must either catch it or pass it on. Here the exception is passed on from main:

import java.text.NumberFormat;
import java.text.ParseException;
import java.util.Locale;

public class ParseExceptionExample {
    public static void main(String[] args) throws ParseException {
        NumberFormat nf = NumberFormat.getInstance(Locale.US);
        System.out.println(nf.parse("1234.567"));
        nf.setParseIntegerOnly(true);
        System.out.println(nf.parse("1234.567"));
    }
}

1234.567
1234

The locale is set explicitly because without it the result depends on system settings. In German, French or Russian locales the decimal separator is a comma, while in the US locale the comma separates groups of digits: there the string "1234,567" becomes 1234567.

Example 2. Checked ParseException with handling

import java.text.NumberFormat;
import java.text.ParseException;

public class ExceptionExample4 {
    public static void main(String[] args) {
        try {
            parseNumber("sss");
        } catch (ParseException e) {
            System.out.println(e.getMessage());
        }
        System.out.println("End of program.");
    }

    public static void parseNumber(String str) throws ParseException {
        NumberFormat nf = NumberFormat.getInstance();
        System.out.println(nf.parse(str));
    }
}

Unparseable number: "sss"
End of program.

If you remove the throws ParseException declaration from parseNumber(), the program does not compile: error: unreported exception ParseException; must be caught or declared to be thrown.

Common Java exceptions

In practice, the exceptions you see most often are unchecked ones from the RuntimeException branch: NullPointerException, ArrayIndexOutOfBoundsException, ClassCastException, NumberFormatException, ArithmeticException. Among checked ones, it is IOException and its subclasses. The table shows what causes each of them and which message the JVM prints.

Example 3. Unchecked ArrayIndexOutOfBoundsException

public class ExceptionExample2 {
    public static void main(String[] args) {
        int[] array = new int[3];
        System.out.println(array[4]);
    }
}

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Index 4 out of bounds for length 3
	at ExceptionExample2.main(ExceptionExample2.java:4)

Example 4. Unchecked StackOverflowError

public class StackOverflowErrorExample {
    public static void main(String[] args) {
        System.out.println("1");
        main(args);
    }
}

1
1
...
Exception in thread "main" java.lang.StackOverflowError

The main method calls itself with no exit condition. Every call takes space on the stack, and after several thousand calls the stack overflows.

Example 5. Unchecked ClassCastException

public class ClassCastExceptionExample {
    public static void main(String[] args) {
        method(new int[0]);
    }

    private static void method(Object arg) {
        String x = (String) arg;
    }
}

Exception in thread "main" java.lang.ClassCastException: class [I cannot be cast to class java.lang.String ([I and java.lang.String are in module java.base of loader 'bootstrap')

[I is the internal class name of the int[] array. The compiler accepts the cast because the parameter is declared as Object, so the error is detected only at runtime.

Example 6. Unchecked NullPointerException

public class NullPointerExceptionExample {
    public static void main(String[] args) {
        String str = null;
        System.out.println(str.length());
    }
}

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "<local1>" is null

Detailed NPE messages (helpful NullPointerExceptions) appeared in Java 14 and are enabled by default since Java 15. The variable name str is printed instead of <local1> if the class was compiled with the -g option. In Java 8 the message was empty: just java.lang.NullPointerException.

What does this code print: catch (Exception e) and StackOverflowError

A catch (Exception e) block does not catch StackOverflowError or OutOfMemoryError, because Error and Exception are sibling branches of the hierarchy, not parent and child. Their only common ancestor is Throwable. Try to predict the output before you look at it:

public class CatchExceptionDemo {
    static void recurse() {
        recurse();
    }

    public static void main(String[] args) {
        try {
            recurse();
        } catch (Exception e) {
            System.out.println("Caught: " + e);
        }
        System.out.println("End of program");
    }
}

Exception in thread "main" java.lang.StackOverflowError
	at CatchExceptionDemo.recurse(CatchExceptionDemo.java:3)
	at CatchExceptionDemo.recurse(CatchExceptionDemo.java:3)
	...

Neither «Caught» nor «End of program» is printed: the error passes by catch (Exception e) and terminates the program. It would be caught by catch (StackOverflowError e), catch (Error e) or catch (Throwable e), but catching Throwable «just in case» is a common mistake: it also silences JVM failures after which the program cannot work correctly.

Methods of the Throwable class

The Throwable class defines the methods that every exception and error inherits: getting the message, the cause and the stack trace. Subclasses such as Exception add almost no methods of their own, so once you know these methods, you can work with any exception. The full list is in the Throwable documentation.

public class ThrowableMethodsDemo {
    public static void main(String[] args) {
        try {
            Integer.parseInt("abc");
        } catch (NumberFormatException e) {
            System.out.println(e.getMessage());
            System.out.println(e);
            System.out.println(e.getCause());
        }
    }
}

For input string: "abc"
java.lang.NumberFormatException: For input string: "abc"
null

How to create your own exception class and which branch of the hierarchy to put it in, as well as how to throw an exception manually with throw, is covered in separate lessons of this module.