Felhantering i mobil utveckling: vad det är, vilka tekniker och hur man organiserar

Felhantering i iOS: Do-Catch, Throw, Guard Let

Felhantering i Swift bygger på fyra viktiga mekanismer: do-catch, throws, guard let och if-let. Till skillnad från många språk tillåter Swift inte oinfångade undantag — varje fel måste hanteras explicit eller deklareras via throws. Felhantering är en kritisk färdighet för mobilutveckling som direkt påverkar applikationens stabilitet.

Do-Catch och Throw

do-catch är standardblocket för att anropa funktioner markerade med throws. Inuti do anropas en funktion med try, och om den kastar ett fel övergår kontrollen till catch. Olika feltryper kan hanteras via pattern matching. Om ett fel inte hanteras propageras det uppåt i stacken (Error Propagation). För effektiv felhantering i iOS, använd do-catch som primär mekanism.

Throw deklareras i funktionssignaturen: func fetchData() throws -> Data. Det innebär att anropande kod måste hantera felet via try, try? eller try!. try? omvandlar felet till nil, try! orsakar en krasch vid fel (använd endast om du är säker på framgång). Felhantering via throw är obligatorisk praxis i Swift.

Optional/Nullable och Guard Let

Guard let är en konstruktion för tidig utträde ur en funktion om värdet är nil. Till skillnad från if-let kräver guard let en utgång (return, throw, break) i else-grenen. Detta gör koden plattare och mer läsbar — utan nästlade if-block. Om en optional inte kan vara nil — använd force unwrap (!), endast när du är helt säker. I en mobil app hjälper guard let att undvika krascher vid hantering av valfria värden.

Optional Chaining (user?.address?.city) och nil-coalescing (??) är syntaktisk socker för att arbeta med optionals utan att packa upp. På IT Sectr använder vi guard let för att validera API-ingångsparametrar och kräver att teamet undviker force unwrap utan explicit kommentar. En felhanterare på varje nivå skyddar mot oväntade fel.

Felhantering i Android: Try-Catch, Elvis, Sealed Class

Kotlin är det primära språket för Android-utveckling. Det ärver try-catch från Java men lägger till säkrare alternativ: elvis-operatorn, require, check och sealed class. Felhantering i Kotlin bygger på en kombination av dessa mekanismer. Till skillnad från Swift kräver Kotlin inte hantering av kontrollerade undantag (alla undantag är okontrollerade). För felhantering i mobila applikationer på Android, använd sealed class som primärt mönster.

Try-Catch och Elvis-operatorn

Try-catch i Kotlin fungerar som ett uttryck — det returnerar ett värde. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Detta förkortar koden. Elvis-operatorn (?:) är en analog till nil-coalescing för nullable-typer: val name = user?.name ?: "Guest". För felhantering i mobila applikationer är try-catch som uttryck den mest koncisa metoden.

Sealed class är ett kraftfullt verktyg för att modellera framgångs- och feltillstånd. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. När den används i ett when-uttryck kontrollerar kompilatorn fullständigheten av grenarna. Felhantering via sealed class garanterar att inget tillstånd lämnas ohanterat.

// Sealed class + try-catch — typiskt mönster 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}")
    }
}

I exemplet modellerar sealed class NetworkResult två tillstånd: framgång med data och fel med ett meddelande. Funktionen fetchUser returnerar ett resultat i vilket fall som helst, och anropande kod hanterar båda grenarna via when. Detta eliminerar möjligheten för ett ohanterat fel. Felhantering via sealed class är standard för Android-utveckling på IT Sectr.

Felhantering i Kotlin: Result och Either

Result är en inbyggd Kotlin-typ för att representera resultatet av en operation som kan misslyckas. Den tvingar fram hantering av framgång och misslyckande via fold, getOrThrow eller map. Result är användbart i asynkrona kedjor (coroutines). Felhantering med Result är en standard för mobil utveckling i Kotlin.

Result vs Either

Either är en funktionell typ från Arrow-biblioteket som gör det möjligt att returnera ett värde av en av två typer (Left — fel, Right — framgång). Till skillnad från Result kan Either innehålla vilken användardefinierad feltryp som helst. För enkla projekt räcker inbyggt Result; för komplexa projekt, använd Either från Arrow. Valet av felhanteringsverktyg beror på projektets komplexitet.

Felspridning

Felspridning är en mekanism där ett fel sprids uppåt i anropsstacken tills det hanteras. I Kotlin sker detta som standard (okontrollerade undantag). I Swift gäller detta endast för funktioner markerade med throws. Med Result och Either sprids inte fel — de stannar i typen och du måste hantera dem. Detta gör felhantering i mobila applikationer säkrare.

Tabellen visar de viktigaste skillnaderna. iOS kräver explicit feldeklaration (throws), vilket gör koden säkrare men mer utförlig. Android förlitar sig på utvecklarens disciplin. På IT Sectr använder vi sealed class för Android och throws för iOS — detta är bästa praxis för båda plattformarna för felhantering i mobila applikationer.

Crash-rapportering: Crashlytics och Sentry

Crash-rapportering är ett system för att samla in och analysera applikationskrascher. Crash-rapportering är en väsentlig del av felhantering i produktion. Utan det får du veta om problem från användare, vilket är oacceptabelt för produktion. Två huvudverktyg: Firebase Crashlytics (gratis) och Sentry (gratis för grundläggande användning). För felhantering i mobila applikationer, implementera alltid crash-rapportering från första releasen.

Firebase Crashlytics

Crashlytics är en del av Firebase. Det samlar automatiskt in krascher, grupperar dem efter anropsstack och visar antalet påverkade användare. Det stöder loggning av icke-dödliga fel via recordException(). Integration: lägg till SDK i build.gradle (Android) eller Podfile (iOS). Crashlytics är det bästa gratisverktyget för felhantering vid start av ett projekt.

Sentry

Sentry är ett plattformsoberoende felövervakningssystem. Till skillnad från Crashlytics erbjuder Sentry detaljerad spårning (breadcrumbs), prestandaövervakning och stöd för React Native. Det gör det möjligt att visa applikationens tillstånd vid felögonblicket. IT Sectr rekommenderar Sentry för projekt som behöver fullständig kontroll över felhantering i mobil utveckling.

Error Boundary i React Native

Error Boundary är en React-komponent som fångar JavaScript-fel i det underordnade komponentträdet och visar ett reservgränssnitt, vilket förhindrar en fullständig appkrasch. Error Boundary är en nyckelkomponent för felhantering i React Native. Använd error boundaries för kritiska skärmar och navigering. Felhantering i mobila applikationer på React Native kräver korrekt inställning av Error Boundary på högsta nivå.

Implementering av Error Boundary

Error Boundary skapas via componentDidCatch(error, errorInfo) eller static getDerivedStateFromError(error). Det fångar inte fel i asynkron kod (setTimeout, requestAnimationFrame), server-side rendering eller inbyggda fel (Native Modules). För loggning, använd crash-rapportering SDK inom componentDidCatch. Error Boundary är en enkel men effektiv felhanterare för UI-lagret.

Dödliga vs icke-dödliga fel

Dödligt fel är ett ohanterat undantag som orsakar en applikationskrasch. Icke-dödligt fel är ett undantag som du fångade och hanterade, men som indikerar ett problem i koden. Icke-dödliga fel loggas via Crashlytics/Sentry och hjälper till att hitta buggar innan de blir dödliga. Både dödliga och icke-dödliga fel kräver korrekt felhantering i mobil utveckling.