withTimeout – hängende Coroutines nach X Sekunden abbrechen
Ein Netzwerkaufruf, der ewig hängt, blockiert deinen Ladezustand für immer. Mit `withTimeout` gibst du einer Coroutine eine Frist – läuft sie ab, bricht Kotlin sie sauber ab.
Ein Server antwortet mal nicht, das Mobilfunknetz ist lahm – und dein Ladespinner dreht sich in alle Ewigkeit. Damit ein Aufruf nicht unbegrenzt hängt, gibst du ihm mit withTimeout eine feste Frist.
Variante 1: Timeout als Fehler
withTimeout wirft eine TimeoutCancellationException, wenn der Block nicht rechtzeitig fertig wird. Die fängst du wie einen normalen Fehler ab:
suspend fun ladeProfil(): Profile = try {
withTimeout(5_000) { // maximal 5 Sekunden
api.getProfile() // ein suspend-Aufruf
}
} catch (e: TimeoutCancellationException) {
throw AppError("Zeitüberschreitung – bitte erneut versuchen")
}Variante 2: null statt Ausnahme
Oft willst du gar keinen Fehler, sondern einfach „nichts". Dafür gibt es withTimeoutOrNull – es liefert null, wenn die Zeit abläuft:
val profil: Profile? = withTimeoutOrNull(5_000) { api.getProfile() }
if (profil == null) {
// Fallback: Cache anzeigen, Hinweis einblenden …
}Wichtig: withTimeout bricht die Coroutine kooperativ ab. Das funktioniert nur, wenn dein Code auf Abbrüche reagiert – bei suspend-Funktionen aus kotlinx.coroutines (Retrofit, Ktor, delay) ist das automatisch der Fall. Reiner, blockierender Java-Code (Thread.sleep, ein synchroner Stream) merkt vom Timeout nichts; solche Aufrufe gehören ohnehin auf Dispatchers.IO und brauchen ein eigenes Zeitlimit.
Robuste Ladezustände sind der Unterschied zwischen „App hängt" und „App fühlt sich schnell an". Wenn du so etwas für deine Android-App brauchst: 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.