هرمية الاستثناءات

Written Explanation

The tree

Every exception and error in Java is a class, and all of them descend from one class: java.lang.Throwable. The Java API documentation says only Throwable and its subclasses can be thrown with throw or named in a catch. Below it the tree splits:

Object
  Throwable
    Error                      (serious problems with the JVM or system)
      OutOfMemoryError, StackOverflowError, ...
    Exception                  (problems your program may meet)
      IOException              (checked)
        FileNotFoundException
      ... other checked exceptions
      RuntimeException         (unchecked)
        IllegalArgumentException
          NumberFormatException
        IllegalStateException
        NullPointerException
        ArithmeticException
        ArrayIndexOutOfBoundsException (via IndexOutOfBoundsException)

You can check any exception's ancestry with a short program that follows getSuperclass() upward. Real output for three types:

public class Chain {
    static void show(Throwable t) {
        StringBuilder sb = new StringBuilder(t.getClass().getSimpleName());
        Class<?> c = t.getClass().getSuperclass();
        while (c != null) {
            sb.append(" -> ").append(c.getSimpleName());
            c = c.getSuperclass();
        }
        System.out.println(sb);
    }

    public static void main(String[] args) {
        show(new NumberFormatException());
        show(new java.io.FileNotFoundException());
        show(new StackOverflowError());
    }
}

NumberFormatException -> IllegalArgumentException -> RuntimeException -> Exception -> Throwable -> Object
FileNotFoundException -> IOException -> Exception -> Throwable -> Object
StackOverflowError -> VirtualMachineError -> Error -> Throwable -> Object

(That program uses Class and getSuperclass() only to show the tree; you will not need them in everyday code.)

The three groups

The group of a class depends on one thing: which branch it descends from.

The Java API documentation states this rule: Throwable and any subclass that is not also a subclass of RuntimeException or Error is a checked exception for compile-time purposes. Unchecked is the name for the other two groups together.

So a short test works for any class: walk up. If you meet Error, it is an error. If you meet RuntimeException, it is unchecked. If you reach Exception without meeting either, it is checked.

Errors: leave them alone

An Error signals a serious problem in the runtime or environment, such as OutOfMemoryError (the JVM could not get memory) or StackOverflowError (the call stack ran out, as in runaway recursion from BEG-014). The Oracle tutorial describes errors as external conditions an application usually cannot anticipate or recover from. By the time one is thrown, your program has probably lost the resources it needs to repair itself.

The practical rule: do not write code that catches Error. Fix the underlying cause instead, for example by adding the missing base case to a recursive method. A running server may end up logging the error and restarting; that is a decision for the platform, not for ordinary business code.

Unchecked exceptions: bugs

RuntimeException and its children usually mean the program has a bug: the caller passed null, an index is wrong, a value is out of the allowed range. The compiler does not make you declare or catch them, and the Oracle tutorial says it is usually better to fix the bug than to catch the exception.

You already met several. IllegalArgumentException and IllegalStateException, which you threw in the encapsulation module, are unchecked: the compiler never asked you to wrap withdraw in anything.

Checked exceptions: the compiler asks for a plan

A checked exception is a problem a well-written program should anticipate: a file may not exist, a network may be down. The compiler enforces what the Oracle tutorial calls the Catch or Specify Requirement: any code that can throw a checked exception must either catch it, or declare that the method may throw it. If you do neither, the code does not compile.

Here is the error. The program tries to throw an IOException and does nothing about it:

public class Bad {
    public static void main(String[] args) {
        System.out.println("Start");
        throw new java.io.IOException("disk full");
    }
}

Real compiler output:

Bad.java:4: error: unreported exception IOException; must be caught or declared to be thrown
        throw new java.io.IOException("disk full");
        ^
1 error

The message tells you exactly what the language wants: caught (next lesson) or declared (the lesson after). Change the type to IllegalStateException and the same program compiles, runs, and prints Start followed by a stack trace, because no plan is required for unchecked exceptions.

Rule of thumb: which kind to choose

When you design your own exceptions later in this module, you will pick a branch. The traditional advice is:

• Checked when the caller can reasonably recover and the failure is part of the method's honest contract: "this file might not be there", "this account might not have enough money". The compiler makes sure nobody forgets the case.
• Unchecked for programming mistakes, such as passing null or a negative quantity. The caller should have checked first, and handling it everywhere would only add noise.

This is a guideline, not a law. The Oracle tutorial notes that some programmers use unchecked exceptions to avoid the requirement, but generally advises against that. Many modern frameworks also prefer unchecked exceptions in their APIs. Keep the guideline in mind and look at what each library or team does.