Fehlerbehandlung in der mobilen Entwicklung: was es ist, welche Techniken und wie man sie organisiert

Fehlerbehandlung in iOS: Do-Catch, Throw, Guard Let

Die Fehlerbehandlung in Swift basiert auf vier Schlüsselmechanismen: do-catch, throws, guard let und if-let. Im Gegensatz zu vielen Sprachen erlaubt Swift keine nicht abgefangenen Ausnahmen — jeder Fehler muss explizit behandelt oder über throws deklariert werden. Die Fehlerbehandlung ist eine kritische Fähigkeit für die mobile Entwicklung, die sich direkt auf die Stabilität der Anwendung auswirkt.

Do-Catch und Throw

do-catch ist der Standardblock zum Aufrufen von Funktionen, die mit throws markiert sind. Innerhalb von do wird eine Funktion mit try aufgerufen, und wenn sie einen Fehler auslöst, geht die Kontrolle an catch über. Verschiedene Fehlertypen können über Pattern Matching behandelt werden. Wenn ein Fehler nicht behandelt wird, propagiert er den Stack hinauf (Error Propagation). Für eine effektive Fehlerbehandlung in iOS verwenden Sie do-catch als primären Mechanismus.

Throw wird in der Funktionssignatur deklariert: func fetchData() throws -> Data. Das bedeutet, dass der aufrufende Code den Fehler über try, try? oder try! behandeln muss. try? wandelt den Fehler in nil um, try! verursacht bei einem Fehler einen Absturz (nur verwenden, wenn Sie sich des Erfolgs sicher sind). Die Fehlerbehandlung über throw ist in Swift eine zwingende Praxis.

Optional/Nullable und Guard Let

Guard let ist ein Konstrukt für den vorzeitigen Ausstieg aus einer Funktion, wenn der Wert nil ist. Im Gegensatz zu if-let erfordert guard let einen Ausstieg (return, throw, break) im else-Zweig. Dies macht den Code flacher und lesbarer — ohne verschachtelte if-Blöcke. Wenn ein Optional nicht nil sein kann — verwenden Sie Force Unwrap (!), nur wenn Sie absolut sicher sind. In einer mobilen App hilft guard let, Abstürze bei der Behandlung optionaler Werte zu vermeiden.

Optional Chaining (user?.address?.city) und nil-coalescing (??) sind syntaktischer Zucker für die Arbeit mit Optionals ohne Auspacken. Bei IT Sectr verwenden wir guard let zur Validierung von API-Eingabeparametern und bestehen darauf, dass das Team Force Unwrap ohne expliziten Kommentar vermeidet. Ein Fehlerhandler auf jeder Ebene schützt vor unerwarteten Ausfällen.

Fehlerbehandlung in Android: Try-Catch, Elvis, Sealed Class

Kotlin ist die primäre Sprache für die Android-Entwicklung. Es erbt try-catch von Java, fügt aber sicherere Alternativen hinzu: den Elvis-Operator, require, check und sealed class. Die Fehlerbehandlung in Kotlin basiert auf einer Kombination dieser Mechanismen. Im Gegensatz zu Swift müssen in Kotlin geprüfte Ausnahmen nicht behandelt werden (alle Ausnahmen sind unchecked). Für die Fehlerbehandlung in mobilen Anwendungen unter Android verwenden Sie sealed class als primäres Muster.

Try-Catch und Elvis-Operator

Try-catch funktioniert in Kotlin als Ausdruck — es gibt einen Wert zurück. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Dies verkürzt den Code. Der Elvis-Operator (?:) ist ein Analogon zu nil-coalescing für nullable-Typen: val name = user?.name ?: "Guest". Für die Fehlerbehandlung in mobilen Anwendungen ist try-catch als Ausdruck der prägnanteste Ansatz.

Sealed class ist ein leistungsstarkes Werkzeug zur Modellierung von Erfolgs- und Fehlerzuständen. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Bei Verwendung in einem when-Ausdruck überprüft der Compiler die Vollständigkeit der Zweige. Die Fehlerbehandlung über sealed class garantiert, dass kein Zustand unbehandelt bleibt.

// Sealed class + try-catch — typisches Muster für Android
sealed class NetworkResult<out T> {
    data class Success<out T>(val data: T) : NetworkResult<T>()
    data class Error(val message: String) : NetworkResult<Nothing>()
}

fun fetchUser(id: String): NetworkResult<User> {
    return try {
        NetworkResult.Success(api.getUser(id))
    } catch (e: Exception) {
        NetworkResult.Error("Failed: ${e.message}")
    }
}

Im Beispiel modelliert die sealed class NetworkResult zwei Zustände: Erfolg mit Daten und Fehler mit einer Nachricht. Die Funktion fetchUser gibt in jedem Fall ein Ergebnis zurück, und der aufrufende Code behandelt beide Zweige über when. Dies schließt die Möglichkeit eines unbehandelten Fehlers aus. Die Fehlerbehandlung über sealed class ist der Standard für die Android-Entwicklung bei IT Sectr.

Fehlerbehandlung in Kotlin: Result und Either

Result ist ein integrierter Kotlin-Typ zur Darstellung des Ergebnisses einer Operation, die fehlschlagen kann. Er erzwingt die Behandlung von Erfolg und Misserfolg über fold, getOrThrow oder map. Result ist in asynchronen Ketten (Coroutinen) nützlich. Die Fehlerbehandlung mit Result ist ein Standard für die mobile Entwicklung in Kotlin.

Result vs Either

Either ist ein funktionaler Typ aus der Arrow-Bibliothek, der es ermöglicht, einen Wert von einem von zwei Typen zurückzugeben (Left — Fehler, Right — Erfolg). Im Gegensatz zu Result kann Either jeden benutzerdefinierten Fehlertyp enthalten. Für einfache Projekte reicht das integrierte Result aus, für komplexe Projekte verwenden Sie Either von Arrow. Die Wahl des Fehlerbehandlungswerkzeugs hängt von der Komplexität des Projekts ab.

Fehlerpropagation

Fehlerpropagation ist ein Mechanismus, bei dem ein Fehler den Aufrufstapel hinauf propagiert, bis er behandelt wird. In Kotlin geschieht dies standardmäßig (unchecked-Ausnahmen). In Swift gilt dies nur für Funktionen, die mit throws markiert sind. Bei Result und Either propagieren Fehler nicht — sie bleiben im Typ und müssen behandelt werden. Dies macht die Fehlerbehandlung in mobilen Anwendungen sicherer.

Die Tabelle zeigt die wichtigsten Unterschiede. iOS erfordert eine explizite Fehlerdeklaration (throws), was den Code sicherer, aber ausführlicher macht. Android verlässt sich auf die Disziplin der Entwickler. Bei IT Sectr verwenden wir sealed class für Android und throws für iOS — das ist die bewährte Methode beider Plattformen für die Fehlerbehandlung in mobilen Anwendungen.

Crash Reporting: Crashlytics und Sentry

Crash Reporting ist ein System zur Erfassung und Analyse von Anwendungsabstürzen. Crash Reporting ist ein wesentlicher Bestandteil der Fehlerbehandlung in der Produktion. Ohne ihn erfahren Sie von Benutzern von Problemen, was für die Produktion inakzeptabel ist. Zwei Hauptwerkzeuge: Firebase Crashlytics (kostenlos) und Sentry (kostenlos für die Basisanwendung). Für die Fehlerbehandlung in mobilen Anwendungen implementieren Sie ab der ersten Version immer ein Crash Reporting.

Firebase Crashlytics

Crashlytics ist Teil von Firebase. Es sammelt automatisch Abstürze, gruppiert sie nach Aufrufstapel und zeigt die Anzahl der betroffenen Benutzer an. Es unterstützt die Protokollierung nicht-fataler Fehler über recordException(). Integration: Fügen Sie das SDK zu build.gradle (Android) oder Podfile (iOS) hinzu. Crashlytics ist das beste kostenlose Werkzeug für die Fehlerbehandlung beim Start eines Projekts.

Sentry

Sentry ist ein plattformübergreifendes Fehlerüberwachungssystem. Im Gegensatz zu Crashlytics bietet Sentry detaillierte Ablaufverfolgung (Breadcrumbs), Leistungsüberwachung und React Native-Unterstützung. Es ermöglicht die Anzeige des Anwendungszustands zum Zeitpunkt des Fehlers. IT Sectr empfiehlt Sentry für Projekte, die eine vollständige Kontrolle über die Fehlerbehandlung in der mobilen Entwicklung benötigen.

Error Boundary in React Native

Error Boundary ist eine React-Komponente, die JavaScript-Fehler im untergeordneten Komponentenbaum abfängt und eine Fallback-Benutzeroberfläche anzeigt, wodurch ein vollständiger App-Absturz verhindert wird. Error Boundary ist eine Schlüsselkomponente für die Fehlerbehandlung in React Native. Verwenden Sie Error Boundaries für kritische Bildschirme und Navigation. Die Fehlerbehandlung in mobilen Anwendungen unter React Native erfordert eine ordnungsgemäße Einrichtung von Error Boundary auf der obersten Ebene.

Error Boundary-Implementierung

Error Boundary wird über componentDidCatch(error, errorInfo) oder static getDerivedStateFromError(error) erstellt. Es fängt keine Fehler in asynchronem Code (setTimeout, requestAnimationFrame), serverseitigem Rendering oder nativen Fehlern (Native Modules). Verwenden Sie für die Protokollierung das Crash Reporting SDK innerhalb von componentDidCatch. Error Boundary ist ein einfacher, aber effektiver Fehlerhandler für die UI-Ebene.

Fatale vs. nicht-fatale Fehler

Fataler Fehler ist eine unbehandelte Ausnahme, die zu einem Anwendungsabsturz führt. Nicht-fataler Fehler ist eine Ausnahme, die Sie abgefangen und behandelt haben, die aber auf ein Problem im Code hinweist. Nicht-fatale Fehler werden über Crashlytics/Sentry protokolliert und helfen, Fehler zu finden, bevor sie fatal werden. Sowohl fatale als auch nicht-fatale Fehler erfordern eine ordnungsgemäße Fehlerbehandlung in der mobilen Entwicklung.