Fehlerbehandlung in Kotlin: try/catch und fortgeschrittene Techniken

Einleitung: Warum reicht das standardmäßige try/catch nicht aus?

Die Entwicklung mit Kotlin, insbesondere im Kontext von Serveranwendungen oder Android, steht oft vor der Notwendigkeit einer zuverlässigen Fehlerbehandlung. Der standardmäßige try/catch-Block ist die Basis, führt aber in der Praxis zu einer „Verschmierung“ der Logik und erschwert das Testen. Auf fortgeschrittenem Niveau möchten wir Ausnahmen nicht nur abfangen, sondern das System so entwerfen, dass Fehler ein Teil des Datentyps sind und nicht ein unerwarteter Kontrollfluss.

In diesem Artikel werden wir uns ansehen, wie man über try/catch hinausgeht und funktionale Ansätze verwendet: Result, Either (aus Bibliotheken) und sealed class. Sie erfahren, wie Sie Code vorhersagbar, typsicher und leicht wartbar machen.

1. Klassisches try/catch: Wann ist es noch nützlich?

Man sollte nicht vollständig auf try/catch verzichten. Es ist unverzichtbar für die Arbeit mit Legacy-Code, externen Bibliotheken (z. B. beim JSON-Parsing) und Systemaufrufen (Ein-/Ausgabe). Es gibt jedoch wichtige Nuancen.

Richtige Struktur und Ressourcen

In Kotlin gibt es im Gegensatz zu Java keine geprüften Ausnahmen, aber es gibt die elegante Konstruktion use zum automatischen Schließen von Ressourcen:

fun readFile(path: String): String? = try {\n    BufferedReader(FileReader(path)).use { it.readText() }\n} catch (e: IOException) {\n    println("Fehler beim Lesen der Datei: ${e.message}")\n    null\n}

Hier stellt use das Schließen der Datei sicher, selbst wenn innerhalb eine Ausnahme aufgetreten ist. Dies ist ein eleganter Ersatz für try-with-resources.

Problem: Kontextverlust

Der Hauptnachteil von try/catch ist, dass es dem aufrufenden Code nicht mitteilt, dass die Funktion „fehlschlagen“ kann. Eine Ausnahme ist ein versteckter Nebeneffekt. Der Aufruf von readFile() kann null zurückgeben oder eine IOException werfen, aber die Funktionssignatur spiegelt dies nicht wider. Dies führt zu Laufzeitfehlern.

Die Lösung besteht darin, zu einer expliziten Darstellung von Fehlern überzugehen.

2. Result: Eingebaute Monade für Erfolg oder Misserfolg

Kotlin bietet die Standardklasse Result<T>. Sie ist eine einfache algebraische Struktur: entweder Erfolg (Wert T) oder Misserfolg (Throwable). Dies macht die Fehlerbehandlung zu einem Teil des Typsystems.

Grundlegende Verwendung

fun riskyDivision(a: Int, b: Int): Result<Int> = runCatching {\n    a / b\n}\n\nfun main() {\n    val result = riskyDivision(10, 0)\n    result.onSuccess { println("Ergebnis: $it") }\n         .onFailure { println("Fehler: ${it.message}") }\n}

runCatching ist ein Wrapper um try/catch, der ein Result zurückgibt. Die Methoden onSuccess und onFailure ermöglichen es, auf den Ausgang zu reagieren, ohne die Aufrufkette zu unterbrechen.

Transformation und Verkettung

Sie können das Ergebnis transformieren, ohne sich um Ausnahmen innerhalb von map zu kümmern:

val finalResult = riskyDivision(10, 2)\n    .map { it * 2 }          // bei Erfolg - multiplizieren\n    .recover { error ->      // bei Fehler - Ersatzwert zurückgeben\n        println("Verwende Ersatzwert aufgrund von: ${error.message}")\n        0\n    }\nprintln(finalResult.getOrDefault(-1)) // 10

Wichtig: Result ist nicht für die Speicherung in Sammlungen oder die Übergabe zwischen Threads ohne zusätzliche Verarbeitung gedacht. Für diese Zwecke eignen sich sealed class oder Bibliotheken wie Arrow besser.

3. Either: Unterscheidung des Fehlertyps

Die Klasse Result erfasst nur Throwable. Aber oft möchten wir Fehlertypen unterscheiden: „nicht gefunden“, „unzureichende Berechtigungen“, „Validierungsfehler“. Hier kommt Either<L, R> aus funktionalen Bibliotheken (z. B. Arrow oder selbst