Non-Fatal Error i mobilapplikationer — innebörd, typer och felhantering

Vad är Non-Fatal Error

Non-Fatal Error — är ett undantag eller feltillstånd som inte orsakar att processen avslutas. Applikationen fortsätter att fungera men kan vara i ett felaktigt tillstånd: data laddades inte, begäran skickades inte, gränssnittselementet visades inte. Användaren märker antingen inte felet eller ser ett meddelande och fortsätter att använda applikationen.

Viktiga kännetecken

Ett icke-fatalt fel lämnar alltid programmet en väg till återställning. Felhanteraren kan erbjuda alternativa data, göra om operationen eller visa en gränssnittsplatshållare. Huvuduppgiften är att förhindra krasch och bibehålla användarupplevelsen på en acceptabel nivå. Utvecklaren måste uttryckligen förutse ett återställningsscenario i varje catch-block.

Roll i applikationsstabilitet

Enligt uppgifter från Instabug 2024 tar 65% av användarna bort applikationen efter två misslyckade interaktioner. Non-fatal fel som lämnas utan uppmärksamhet ackumuleras och minskar den övergripande kvaliteten. Systematisk loggning och korrigering av icke-fatala fel är en direkt väg till ökad retention och förbättrade användarbetyg i appbutiker.

Typer av icke-fatala fel

Nätverksfel — den vanligaste typen av non-fatal fel i mobilapplikationer. Anslutningstidsgräns, nätverksförlust, felaktig serverstatuskod — alla dessa situationer fångas upp och hanteras utan krasch. Användaren visas ett meddelande om att tjänsten inte är tillgänglig med förslag om att försöka igen. För nätverksfel är mönstret retry med exponentiell fördröjning typiskt.

Datavalideringsfel

Felaktigt format på serverrespons, saknat obligatoriskt fält, felaktig datatyp — tolkningfel är icke-fatala om applikationen korrekt hanterar felaktiga data. Den typiska metoden är att använda standard reservvärden och logga tolkningfelet med begärandekontext för senare analys på servern.

UI-renderingsfel

Problem med bildladdning, felaktiga typsnitt, layoutfel — ingen av dessa är fatala men försämrar användarens intryck. Platshållarbilder och fallback-värden gör det möjligt att undvika tomma skärmar och gör fel mindre synliga. I React Native används Error Boundary för UI-fel med visning av en reservkomponent.

Affärslogik- och tillståndsfel

Fel i beräkningar, tillståndsinkonsekvenser, felaktiga övergångar mellan skärmar — logiska fel leder ofta inte till krasch men leder till felaktigt beteende hos applikationen. De är svårare att upptäcka utan systematisk loggning och övervakning eftersom de inte skapar kraschrapporter och förblir oupptäckta tills användaren klagar.

Non-Fatal Error vs Fatal Error: jämförelse

Non-Fatal Error skiljer sig från fatal genom att det lämnar programmet möjlighet att fortsätta arbeta. Fatal error — är ett tillstånd som applikationen inte kan återhämta sig från: null-pekar-dereferens, stack overflow, minnesbrist. Ett non-fatal fel kan fångas upp, hanteras och exekveringen kan fortsätta, medan fatal error kräver omstart av applikationen.

Gränsen mellan non-fatal och fatal kan bero på implementationen. Nätverkstidsgräns i en applikation hanteras som non-fatal (upprepning av begäran efter 1–2 sekunder), i en annan kan den vara fatal (krasch vid avsaknad av hanterare). Kvalitativ felhantering omvandlar potentiellt fatala situationer till icke-fatala, vilket ökar applikationens stabilitet. Utformning av felhanteringssystemet är en av de viktigaste arkitektoniska uppgifterna vid utveckling av en mobilapplikation med höga krav på tillförlitlighet. Det inbyggda övervakningssystemet gör det möjligt för teamet att snabbt upptäcka och åtgärda icke-fatala fel innan de påverkar ett betydande antal användare.

Loggning av non-fatal fel

Firebase Crashlytics — det främsta verktyget för loggning av icke-fatala fel i mobilapplikationer. Metoden recordException gör det möjligt att registrera ett non-fatal undantag med full stacktrace och exekveringskontext utan att avbryta applikationens drift. Till skillnad från kraschrapporter kan recordException anropas var som helst i koden för att logga fångade undantag.

fun fetchUserData(userId: String) {
    try {
        val response = apiService.getUser(userId)
        updateUI(response)
    } catch (e: IOException) {
        Crashlytics.log("Network error for user $userId")
        Crashlytics.recordException(e)
        showRetryDialog()
    } catch (e: JsonParseException) {
        // Non-fatal: använder reservdata
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// Loggning med användarnycklar
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry — ett alternativ till Crashlytics med mer detaljerad diagnostik av non-fatal fel. Sentry SDK tillhandahåller metoden captureException som skickar undantagsdetaljer till servern. Den viktigaste fördelen med Sentry är gruppering av liknande non-fatal fel i ett enda issue, analys av upprepningsfrekvens och exekveringskontext i form av breadcrumbs — sekvensen av användaråtgärder före felet.

Kriterier för loggning av non-fatal fel

Inte alla non-fatal fel behöver loggas. Förväntade tillstånd — nätverksbortfall vid frånvaro av anslutning — kan loggas selektivt. Oväntade fel — NullPointerException i hanterad kod, felaktigt dataformat, logic error — bör alltid loggas. Varje team bestämmer betydelsetröskeln: i genomsnitt anses 10 till 20 unika non-fatal fel per 1000 användare per dag vara normalt. Det är viktigt att konfigurera varningar för plötslig ökning av antalet non-fatal fel — detta kan indikera problem med en ny API-version eller regression efter en release.

Hantering av non-fatal fel i kod

Den grundläggande hanteringsmekanismen — try-catch, som fångar undantaget och utför återställningskoden. För nätverksoperationer är det typiska mönstret att upprepa begäran med exponentiell fördröjning (retry with backoff). För tolkningfel — användning av standard reservvärden och loggning av kontext för senare analys på serversidan.

func loadImage(from url: URL) -> UIImage? {
    do {
        let data = try Data(contentsOf: url)
        return UIImage(data: data)
    } catch {
        Logger.shared.logError(error: "Image load failed: \(url)")
        return UIImage(named: "placeholder")
    }
}

func performRequest() async throws -> Data {
    var lastError: Error? = nil
    for attempt in 0..<3 {
        do {
            return try await URLSession.shared.data(from: url)
        } catch {
            lastError = error
            try await Task.sleep(UInt64(pow(2, attempt)) * 1_000_000_000)
        }
    }
    throw lastError ?? URLError(.unknown)
}

Result-typer — ett alternativt tillvägagångssätt utan undantag. Funktionen returnerar en sealed class Result med varianterna Success och Failure. Den anropande koden hanterar båda varianterna explicit, vilket eliminerar ohanterade fel. Result-typer är populära i Kotlin (Result i standardbiblioteket) och Swift (Result) för explicit hantering av non-fatal tillstånd på typnivå.

Fallback-strategier för non-fatal fel

För varje typ av non-fatal fel måste en återställningsstrategi förutses: laddning av cachad data vid nätverksfel, användning av standardvärden vid tolkningfel, ominitiering av komponenten vid UI-fel. God praxis är att visa en toast eller snackbar med felmeddelande för användaren, men inte helt blockera interaktionen med applikationen. Det är viktigt att skilja mellan återställningsbara (recoverable) och icke-återställningsbara fel — för de senare kommer återställningsstrategin att vara annorlunda, till exempel förslag om att starta om skärmen eller rensa data. Cachning av föregående framgångsrika tillstånd visar sig ofta vara det enklaste och mest effektiva sättet att hantera non-fatal fel på mobila plattformar.