Wie funktioniert die Ausnahmeverarbeitung und die Unterscheidung zwischen kontrollierten und unkontrollierten Ausnahmen?

Question

Accepted Answer

Java verarbeitet Fehler mit **`try`/`catch`/`finally`** und unterscheidet einzigartig zwischen **kontrollierten** Ausnahmen (müssen deklariert oder behandelt werden) und **unkontrollierten** Ausnahmen (Laufzeit, nicht erzwungen). Das Verständnis dieser Unterscheidung ist zentral für die Fehlerbehandlung in Java.

## Die grundlegende Struktur

```java
try {
    FileReader f = new FileReader("file.txt");   // may throw IOException
    // ... use it ...
} catch (FileNotFoundException e) {
    System.out.println("not found: " + e.getMessage()); // specific first
} catch (IOException e) {
    System.out.println("io error");                      // broader after
} finally {
    System.out.println("always runs — cleanup");         // runs no matter what
}
```

`finally` wird immer ausgeführt (Bereinigung), auch wenn eine Ausnahme geworfen oder ein `return` aufgetreten ist.

## Die Ausnahmehierarchie

```text
Throwable
  ├── Error            — serious JVM problems (OutOfMemoryError) — don't catch
  └── Exception
        ├── RuntimeException  → UNCHECKED (not enforced by the compiler)
        │     NullPointerException, IllegalArgumentException, IndexOutOfBounds...
        └── (other Exceptions) → CHECKED (compiler enforces handling)
              IOException, SQLException...
```

## Kontrollierte Ausnahmen — vom Compiler erzwungen

```java
// MUST either catch it or declare `throws` — the compiler won't let you ignore it
public void readFile() throws IOException {   // declare it
    Files.readAllLines(Paths.get("file.txt")); // throws checked IOException
}
```

**Kontrollierte** Ausnahmen (IOException, SQLException) stellen wiederherstellbare, erwartete Bedingungen dar (eine fehlende Datei, ein Netzwerkfehler). Der Compiler *zwingt* Sie, sie zu behandeln oder zu deklarieren — was die Behandlung externer Fehler explizit macht.

## Unkontrollierte Ausnahmen — Laufzeit, nicht erzwungen

```java
// NOT required to declare or catch — usually indicate PROGRAMMING BUGS
String s = null;
s.length();                       // NullPointerException (unchecked)
int x = arr[10];                   // ArrayIndexOutOfBoundsException (unchecked)
Integer.parseInt("abc");           // NumberFormatException (unchecked)
```

**Unkontrollierte** (RuntimeException-Unterklassen) signalisieren normalerweise Programmierfehler — Sie beheben den Fehler, anstatt ihn überall abzufangen. Der Compiler erzwingt keine Behandlung.

## try-with-resources (Automatische Bereinigung)

```java
// resources implementing AutoCloseable are closed automatically
try (FileReader f = new FileReader("file.txt")) {
    // use f
}   // f.close() called automatically, even on exception — no finally needed
```

## Best Practices

```text
✓ Catch specific exceptions, not bare Exception
✓ Use try-with-resources for files/connections (auto-close)
✓ Don't swallow exceptions silently (empty catch blocks)
✓ Throw meaningful exceptions; include context in messages
✓ Custom exceptions extend Exception (checked) or RuntimeException (unchecked)
```

## Warum es wichtig ist

Robuste Fehlerbehandlung ist essentiell, und Javas **Unterscheidung zwischen kontrollierten und unkontrollierten Ausnahmen ist ein charakteristisches (und umstrittenes) Merkmal**, das es verdient, tiefgehend verstanden zu werden.

Kontrollierte Ausnahmen erzwingen die explizite Behandlung erwarteter externer Fehler (I/O, DB) — fördern Zuverlässigkeit, aber werden manchmal als ausschweifend kritisiert; unkontrollierte Ausnahmen stellen Fehler dar, die behoben werden sollten, statt sie routinemäßig abzufangen.

Die Kenntnis der Hierarchie, wann jede Art gilt, die Semantik von `try/catch/finally` und modernes **try-with-resources** für automatische Bereinigung ist grundlegend für das Schreiben korrekter, zuverlässiger Java — und für das angemessene Design eigener Ausnahmen.

Die Unterscheidung prägt, wie Java-APIs entworfen werden, und ist ein häufiges Thema in Interviews und Code-Reviews.