Java-Exceptions: Fehler, Stack-Traces und Werfen

Was eine Exception ist

Eine Exception ist Javas Art zu sagen: „Etwas ist schiefgelaufen und ich kann nicht normal weitermachen." Statt einen falschen Wert zurückzugeben oder deine Daten stillschweigend zu beschädigen, erzeugt die Laufzeitumgebung ein Exception-Objekt, das das Problem beschreibt, und wirft es. Die normale Ausführung stoppt an dieser Stelle, und Java beginnt, nach Code zu suchen, der weiß, wie man mit der Situation umgeht.

Behandelt sie niemand, erreicht die Exception die Spitze deines Programms, die JVM gibt einen Stack-Trace aus, und der Prozess beendet sich mit einem Status ungleich null.

public class Main {
    public static void main(String[] args) {
        int[] numbers = {10, 20, 30};
        System.out.println("before");
        System.out.println(numbers[5]);   // Index 5 existiert nicht
        System.out.println("after");      // wird nie ausgeführt
    }
}

Beachte, dass "after" nie ausgegeben wird. In dem Moment, in dem numbers[5] ausgewertet wird, wird eine ArrayIndexOutOfBoundsException geworfen und der Rest von main wird verworfen.

Einen Stack-Trace lesen

Wenn eine Exception unbehandelt bleibt, erhältst du eine Ausgabe wie diese. Sie wirkt einschüchternd, ist aber nur eine Liste:

Exception in thread "main" java.lang.ArithmeticException: / by zero
	at Main.divide(Main.java:8)
	at Main.main(Main.java:4)

Lies sie von oben nach unten:

• Die erste Zeile ist der Typ (ArithmeticException) und eine Meldung (/ by zero).
• Jede at ...-Zeile ist ein Stack-Frame. Die oberste ist die Stelle, an der die Exception tatsächlich geworfen wurde - divide in Zeile 8. Darunter steht der Aufrufer, main in Zeile 4.

Die oberste at-Zeile ist die Stelle, an der du zuerst nachschaust. Die Frames darunter beantworten die Frage „Wie sind wir hierher gekommen?".

public class Main {
    static int divide(int a, int b) {
        return a / b;            // wirft, wenn b gleich 0 ist
    }

    public static void main(String[] args) {
        System.out.println(divide(10, 2));
        System.out.println(divide(10, 0));   // Knall
    }
}

Führe dies aus, und der Trace zeigt direkt auf die Zeile a / b und dann main als Aufrufer. Diese Aufrufkette ist das nützlichste Debugging-Werkzeug, das Java dir gratis schenkt.

Die Exception-Hierarchie

Jede Exception ist ein Objekt, und alle stammen von Throwable ab. Die beiden Zweige, die zählen:

• Error - schwerwiegende Probleme, die die JVM auslöst, wie OutOfMemoryError oder StackOverflowError. Diese fängst du in der Regel nicht.
• Exception - Probleme, die dein Programm vernünftigerweise vorhersehen und behandeln kann. Darin sitzt RuntimeException, der Elternteil der alltäglichen Bugs wie NullPointerException.

Throwable
├── Error                 (don't catch: OutOfMemoryError, StackOverflowError)
└── Exception
    ├── IOException        (checked)
    ├── SQLException       (checked)
    └── RuntimeException   (unchecked)
        ├── NullPointerException
        ├── ArithmeticException
        └── ArrayIndexOutOfBoundsException

Weil dies echte Klassen sind, kann eine Exception eine Meldung tragen, und du kannst sie über sich selbst befragen:

public class Main {
    public static void main(String[] args) {
        try {
            int x = 10 / 0;
        } catch (ArithmeticException e) {
            System.out.println("type: " + e.getClass().getSimpleName());
            System.out.println("message: " + e.getMessage());
        }
    }
}

getMessage() liefert den Text nach dem Doppelpunkt im Stack-Trace; getClass().getSimpleName() gibt dir den Exception-Typ als Namen.

Checked vs. unchecked

Das ist die Unterscheidung, die Neulinge am meisten verwirrt.

• Unchecked Exceptions erweitern RuntimeException. Sie bedeuten meist einen Bug in deinem Code - ein unerwartetes null, ein falscher Index, eine Division durch null. Der Compiler zwingt dich nicht, sie zu behandeln.
• Checked Exceptions erweitern Exception, aber nicht RuntimeException (zum Beispiel IOException). Sie stehen für Bedingungen außerhalb deiner Kontrolle - eine fehlende Datei, eine abgebrochene Netzwerkverbindung. Der Compiler zwingt dich, sie entweder zu fangen oder zu deklarieren.

Wenn eine Methode eine checked Exception werfen kann, muss sie das mit throws angeben, und jeder Aufrufer muss damit umgehen:

public class Main {
    // deklariert, dass sie mit einer checked Exception fehlschlagen kann
    static void risky() throws Exception {
        throw new Exception("something went wrong");
    }

    public static void main(String[] args) throws Exception {
        risky();   // main muss sie ebenfalls behandeln oder erneut deklarieren
    }
}

Entferne throws Exception aus main, und der Code lässt sich nicht einmal kompilieren - das ist der Compiler, der den Vertrag der checked Exceptions durchsetzt. Unchecked Exceptions verlangen das nie.

Eigene Exceptions werfen

Du reagierst nicht nur auf Exceptions - du kannst sie auch auslösen. Verwende throw mit einem neuen Exception-Objekt, um zu signalisieren, dass ein Argument oder ein Zustand ungültig ist. Das ist weitaus besser, als einen magischen Wert wie -1 zurückzugeben und zu hoffen, dass der Aufrufer ihn prüft.

public class Main {
    static int squareRootInput(int n) {
        if (n < 0) {
            throw new IllegalArgumentException("n must be non-negative, got " + n);
        }
        return n;
    }

    public static void main(String[] args) {
        System.out.println(squareRootInput(16));
        System.out.println(squareRootInput(-4));   // wirft mit einer klaren Meldung
    }
}

Füge immer eine Meldung hinzu, die erklärt, was falsch war, und idealerweise den problematischen Wert - dein zukünftiges Ich, das den Stack-Trace liest, wird es dir danken. IllegalArgumentException und IllegalStateException sind die beiden, zu denen du beim Validieren von Eingaben am häufigsten greifst.

Häufige Stolpersteine

• Exceptions verschlucken. Eine Exception zu fangen und nichts zu tun (ein leerer Block) verbirgt Bugs. Logge sie zumindest; meist solltest du sie behandeln oder erneut werfen.
• Exception zu breit fangen. Die Basisklasse Exception (oder schlimmer, Throwable) zu fangen, kann Probleme verbergen, die du nicht behandeln wolltest. Fange den konkreten Typ, den du erwartest.
• Den Trace von unten nach oben lesen. Der relevanteste Frame ist die oberste at-Zeile, nicht die unterste. Beginne dort.
• Error mit Exception verwechseln. Versuche nicht, dich von einem OutOfMemoryError oder StackOverflowError zu erholen; behebe stattdessen die zugrunde liegende Ursache.

Weiter: try-catch

Jetzt weißt du, was Exceptions sind und wie man sie liest. Die nächste Seite behandelt, wie man sie tatsächlich behandelt: riskanten Code in einen try-Block einpacken, im catch reagieren und Aufräumcode im finally ausführen, damit dein Programm weiterläuft, statt abzustürzen.