Was sind die Unterschiede zwischen checked und unchecked Exceptions in Java, wie sollte die Fehlerbehandlung entworfen werden und welche Fehler sollten bei ihrer Verwendung vermieden werden?

Antwort

In Java werden Ausnahmen in checked (überprüfte) und unchecked (nicht überprüfte) unterteilt.

• Checked Exceptions — erben von Exception, aber nicht von RuntimeException. Der Compiler verlangt eine explizite Behandlung mit try-catch oder eine Deklaration in throws.
• Unchecked Exceptions — erben von RuntimeException. Der Compiler verlangt keine zwingende Behandlung.

public void readFile(String file) throws IOException { /* ... */ } // checked
public void divide(int a, int b) { int res = a/b; } // unchecked (ArithmeticException)

Der Hauptunterschied besteht darin, dass checked Exceptions für vorhersehbare, behandelbare Situationen verwendet werden (z.B. Eingabe-/Ausgabefehler), während unchecked Exceptions für Programmfehler oder kritische Situationen verwendet werden, von denen man sich nicht erholen kann (z.B. NullPointerException).

Fangfrage

Frage: Muss eine unchecked Exception behandelt oder in throws deklariert werden, wenn Ihre Methode sie auslösen kann?

Antwort: Nein. Der Compiler verlangt nicht, dass nicht behandelbare (unchecked) Ausnahmen überprüft oder deklariert werden. Ihre Behandlung liegt in Ihrem Ermessen; Sie können try-catch verwenden, aber meist ist es besser, sie "fallen zu lassen", bis zum globalen Handler.

public void foo() { throw new IllegalArgumentException(); } // Erfordert keine Behandlung oder Erklärung

Beispiele für reale Fehler aufgrund fehlenden Wissens über die Feinheiten des Themas

---

Geschichte

In einem Bank-API-Projekt wurden bei der Behandlung von Eingabe-/Ausgabefehlern RuntimeException statt checked geworfen. Infolgedessen waren die Kunden nicht gezwungen, sie zu behandeln, was zu falschem Verhalten bei Verlust der Verbindung zum Server führte, und die Anwendung "stürzte" ab, ohne den Benutzer zu informieren.

---

Geschichte

Ein Entwickler hat eine übermäßige Anzahl von throws Exception in den Methodensignaturen (z.B. für Datenbanken) deklariert, was dazu führte, dass alle verwendeten Methoden entweder try-catch oder ebenfalls throws verwenden mussten. Dies führte zu unübersichtlichem Code, verschlechterte die Lesbarkeit und erschwerte das Refactoring.

---

Geschichte

In einem der Mikrodienste wurden alle Ausnahmen mit einem allgemeinen catch (Exception e) gefangen. Dies schnappte auch unchecked Exceptions (z.B. NullPointerException) auf, was zu "stillem" Ignorieren kritischer Fehler führte – der Dienst arbeitete mit inkorrekten Daten.