Exception Handling in Java: Fehler sauber behandeln statt verstecken

Von Guido Zeuner · Softwareentwickler und Autor von tiny-tool.de

Mit try, catch, throw, throws und try-with-resources steuerst du, wie dein Programm auf außergewöhnliche Situationen reagiert. Entscheidend ist aber nicht, möglichst viele Exceptions abzufangen – sondern sie an der richtigen Stelle sinnvoll zu behandeln.

Gutes Exception Handling hält Fehler nicht geheim. Es bewahrt nützlichen Kontext, schließt Ressourcen zuverlässig und gibt aufrufendem Code eine klare Entscheidungsmöglichkeit: erneut versuchen, einen Ersatzwert verwenden, dem Nutzer eine verständliche Meldung zeigen oder die Verarbeitung kontrolliert beenden.

Was bei einer Exception wirklich passiert

Eine Exception ist ein Objekt aus der Throwable-Hierarchie. Es trägt typischerweise einen Typ, eine Meldung, einen Stacktrace und optional eine Ursache. Wird es mit throw ausgelöst, endet die aktuelle Anweisung abrupt. Java sucht anschließend im aktuellen Block und danach entlang des Aufrufstapels nach einem passenden catch-Block.

Findet Java einen Handler, läuft das Programm dort weiter. Gibt es keinen passenden Handler, erreicht die Exception den Thread-Rand. Der Thread endet dann; bei der main-Methode bedeutet das häufig das Ende des Programms.

static int parsePort(String input) {
    try {
        int port = Integer.parseInt(input);

        if (port < 1 || port > 65_535) {
            throw new IllegalArgumentException(
                    "Port außerhalb des gültigen Bereichs: " + port);
        }

        return port;
    } catch (NumberFormatException e) {
        throw new IllegalArgumentException(
                "Port ist keine ganze Zahl: " + input, e);
    }
}

Das Beispiel behandelt keinen Fehler „weg“. Es übersetzt eine technische NumberFormatException in eine für die Methode passendere Aussage und erhält mit e als zweitem Konstruktorargument die ursprüngliche Ursache.

Die Throwable-Hierarchie verstehen

Checked und unchecked Exceptions

Die Unterscheidung beschreibt zuerst eine Regel des Compilers – nicht automatisch die Schwere eines Problems.

Eine checked Exception ist Teil des sichtbaren Methodenvertrags. Der folgende Code kompiliert nur, weil die mögliche IOException mit throws weitergegeben wird:

static String readConfig(Path file) throws IOException {
    return Files.readString(file, StandardCharsets.UTF_8);
}

Bei einer NullPointerException oder IndexOutOfBoundsException ist ein flächendeckendes catch dagegen selten die Lösung. Meist sollte der fehlerhafte Zustand verhindert oder die Vorbedingung geprüft werden.

„Unchecked“ bedeutet nicht „ignorieren“ und auch nicht „vorsichtshalber überall fangen“. Es bedeutet lediglich, dass der Compiler keine Behandlung erzwingt.

try und catch richtig einsetzen

In den try-Block gehört nur der Bereich, dessen erwartete Fehler du behandeln möchtest. Je kleiner der Block, desto klarer ist, welche Operation gescheitert ist.

static Optional<User> findUser(UserRepository repository, long id) {
    try {
        return repository.findById(id);
    } catch (DatabaseUnavailableException e) {
        metrics.increment("user_lookup_failed");
        throw new ServiceUnavailableException(
                "Benutzerdaten konnten nicht geladen werden", e);
    }
}

Der Handler tut hier drei konkrete Dinge: Er erfasst eine Metrik, übersetzt die technische Exception in die Sprache der Service-Schicht und erhält die Ursache. Ein bloßes System.out.println(e.getMessage()) wäre kein gleichwertiger Ersatz, weil Typ, Stacktrace und Ursache verloren gehen können.

Was ein catch-Block sinnvoll tun kann

• eine Operation mit begrenzter Anzahl und sinnvoller Verzögerung erneut versuchen,
• auf eine definierte Alternative ausweichen,
• die Exception in einen passenderen Abstraktionstyp übersetzen,
• an einer Systemgrenze eine verständliche HTTP-, UI- oder Kommandozeilen-Antwort erzeugen,
• Kontext ergänzen und die Exception weitergeben.

Mehrere Exception-Typen behandeln

Mehrere catch-Blöcke werden von oben nach unten geprüft. Spezifische Typen müssen vor ihren Oberklassen stehen; andernfalls wäre der spezifische Handler unerreichbar und der Code kompiliert nicht.

try {
    importData(file);
} catch (AccessDeniedException e) {
    showMessage("Keine Leseberechtigung für " + file);
} catch (NoSuchFileException e) {
    showMessage("Datei nicht gefunden: " + file);
} catch (IOException e) {
    showMessage("Datei konnte nicht gelesen werden: " + file);
}

Wenn verschiedene Typen exakt gleich behandelt werden, fasst ein Multi-catch sie ohne doppelten Code zusammen:

try {
    settings = loadSettings(source);
} catch (IOException | InvalidSettingsException e) {
    throw new StartupException("Konfiguration ist nicht nutzbar", e);
}

Ressourcen sicher schließen: try-with-resources

Dateien, Streams, Sockets und Datenbankobjekte müssen zuverlässig geschlossen werden. Implementiert ein Objekt AutoCloseable, gehört es in die Ressourcenklausel eines try-Blocks.

static List<String> readNonEmptyLines(Path file) throws IOException {
    try (BufferedReader reader = Files.newBufferedReader(
            file, StandardCharsets.UTF_8)) {

        return reader.lines()
                .map(String::trim)
                .filter(line -> !line.isEmpty())
                .toList();
    }
}

Der Reader wird beim Verlassen des Blocks automatisch geschlossen – bei normaler Rückgabe ebenso wie bei einer Exception. Mehrere Ressourcen werden in umgekehrter Reihenfolge ihrer Deklaration geschlossen.

Was passiert, wenn auch close() scheitert?

Wirft der eigentliche Block eine Exception und zusätzlich das Schließen der Ressource, bleibt die Exception aus dem Block die primäre. Der Fehler aus close() wird als suppressed exception angehängt und ist über getSuppressed() sichtbar. Damit geht die ursprüngliche Ursache nicht verloren.

Wann finally noch sinnvoll ist

finally läuft im regulären JVM-Kontrollfluss unabhängig davon, ob der try-Block normal endet, zurückkehrt oder eine Exception wirft. Sinnvoll ist es für Aufräumarbeiten, die nicht über AutoCloseable modelliert sind – etwa das Zurücksetzen eines Zustands oder das Freigeben eines Locks.

lock.lock();
try {
    updateSharedState();
} finally {
    lock.unlock();
}

throw und throws: ähnlich geschrieben, andere Aufgabe

Vorbedingungen sollten möglichst früh geprüft werden. Dadurch entsteht die Exception nahe an der eigentlichen Ursache:

static BigDecimal applyDiscount(BigDecimal price, int percent) {
    Objects.requireNonNull(price, "price");

    if (percent < 0 || percent > 100) {
        throw new IllegalArgumentException(
                "percent muss zwischen 0 und 100 liegen: " + percent);
    }

    return price.multiply(
            BigDecimal.valueOf(100 - percent, 2));
}

Eigene Exceptions mit fachlicher Bedeutung

Eine eigene Exception lohnt sich, wenn sie einen stabilen Fehlerfall deiner Domäne oder Anwendungsschicht ausdrückt. Der Name sollte dem Aufrufer mehr sagen als ein generisches „etwas ist schiefgelaufen“.

public final class ConfigurationException extends Exception {
    public ConfigurationException(String message, Throwable cause) {
        super(message, cause);
    }
}

static Properties loadConfiguration(Path file)
        throws ConfigurationException {

    Properties properties = new Properties();

    try (Reader reader = Files.newBufferedReader(
            file, StandardCharsets.UTF_8)) {
        properties.load(reader);
        return properties;
    } catch (IOException e) {
        throw new ConfigurationException(
                "Konfiguration konnte nicht gelesen werden: " + file, e);
    }
}

Die Entscheidung zwischen Exception und RuntimeException hängt vom Vertrag ab:

• Checked: Der Aufrufer soll den Fehler bewusst behandeln oder weiterreichen können.
• Unchecked: Der Fehler steht für eine verletzte Vorbedingung, einen ungültigen Zustand oder soll erst an einer höheren Systemgrenze übersetzt werden.

Java und Kotlin: Exception Handling im Vergleich

Java und Kotlin verwenden auf der JVM dieselben Exception-Objekte und Stacktraces. Der sprachliche Vertrag unterscheidet sich jedoch deutlich. Wer beide Sprachen in einem Projekt einsetzt, sollte diese Unterschiede kennen – besonders an gemeinsam genutzten APIs.

try-catch als Ausdruck

In Kotlin kann das Ergebnis eines try– oder catch-Blocks unmittelbar einer Variablen zugewiesen werden. Die fachliche Prüfung bleibt davon getrennt:

fun parsePort(input: String): Int {
    val port = try {
        input.toInt()
    } catch (e: NumberFormatException) {
        throw IllegalArgumentException(
            "Port ist keine ganze Zahl: $input", e
        )
    }

    require(port in 1..65_535) {
        "Port außerhalb des gültigen Bereichs: $port"
    }

    return port
}

Ressourcen mit use schließen

Für schließbare Ressourcen benötigt Kotlin keine eigene Variante von try-with-resources. use schließt die Ressource auch dann, wenn der Block mit einer Exception endet:

fun readConfig(file: Path): List<String> =
    Files.newBufferedReader(file, StandardCharsets.UTF_8).use { reader ->
        reader.readLines()
    }

Threads, Futures und Systemgrenzen

Exceptions überschreiten Thread-Grenzen nicht automatisch. Bei asynchronen APIs werden sie häufig verpackt: CompletableFuture.join() verwendet typischerweise CompletionException, während Future.get() eine ExecutionException liefert. Prüfe bei der Behandlung deshalb auch getCause().

InterruptedException nicht verschlucken

Kann eine Methode InterruptedException nicht weitergeben, sollte sie den Interrupt-Status in der Regel wiederherstellen:

try {
    queue.put(message);
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
    return;
}

Das ist auch bei modernem nebenläufigem Code wichtig: Ein Interrupt ist ein Kooperationssignal zur Beendigung oder Unterbrechung einer Aufgabe, kein gewöhnlicher Fachfehler.

Best Practices und typische Anti-Patterns