runCatching – Fehler in Kotlin funktional statt mit try/catch
Statt jeden Aufruf in try/catch zu wickeln, gibt dir `runCatching` ein Result zurück. Mit `map`, `getOrElse` und `onFailure` liest sich Fehlerbehandlung wie eine saubere Kette.
try/catch ist völlig in Ordnung – aber wenn sich mehrere davon stapeln, wird der Code unruhig. runCatching führt einen Block aus und packt Erfolg oder Fehler in ein Result. Damit lässt sich das Ergebnis wie ein Wert weiterreichen und transformieren.
Result erzeugen und auslesen
val result: Result<Int> = runCatching {
"42".toInt() // könnte NumberFormatException werfen
}
val zahl: Int = result.getOrElse { fehler ->
println("Konnte nicht parsen: ${fehler.message}")
0 // Fallback-Wert
}Verketten mit map und onFailure
map transformiert nur den Erfolgsfall, ohne dass du zwischendurch auspacken musst; onSuccess/onFailure sind für Seiteneffekte (Logging, UI):
fun ladeAlter(input: String): Int =
runCatching { input.trim().toInt() }
.map { alter -> alter.coerceIn(0, 120) } // nur wenn erfolgreich
.onFailure { Log.w("Form", "Ungültiges Alter", it) }
.getOrDefault(0)Zwei Dinge zur Vorsicht: runCatching fängt jeden Throwable – also auch Dinge, die du vielleicht durchreichen willst. In Coroutinen solltest du die CancellationException nicht schlucken; ein getOrElse { if (it is CancellationException) throw it else fallback } hält den Abbruch sauber. Für erwartbare Fehlerfälle ist runCatching aber ein sehr aufgeräumtes Werkzeug.
Sauberer, gut lesbarer Code ist die halbe Wartbarkeit. Wenn du eine Android-App in Kotlin baust und Wert darauf legst, schreib mir über bymw.de.
Quellen
Du brauchst mehr als ein Snippet?
Ich entwickle Android-Apps in Kotlin und moderne Websites für Selbstständige und kleine Unternehmen — von der ersten Idee bis zum Release.
Projekt anfragen →Verwandte Snippets
Fehler in Coroutinen – coroutineScope, supervisorScope und wer wen mitreißt
Eine von fünf parallelen Abfragen scheitert – und plötzlich sind alle abgebrochen. Das ist kein Bug, sondern strukturierte Nebenläufigkeit. Wer den Unterschied zwischen coroutineScope und supervisorScope kennt, steuert das bewusst.
Nach mehreren Kriterien sortieren – sortedWith, compareBy und thenBy
Erst nach Priorität, dann nach Datum, und die ohne Termin ganz nach hinten: Solche Sortierungen werden mit einem handgeschriebenen Comparator schnell unleserlich. Kotlin hat dafür eine Baukastenschreibweise.
Room-Migrationen – das Schema ändern, ohne Nutzerdaten zu verlieren
Eine neue Spalte in der Entity, und beim nächsten Start ist der Spielstand weg – weil fallbackToDestructiveMigration die Datenbank einfach löscht. So machst du es richtig, inklusive Test.