Non-Fatal Error in mobiele applicaties — essentie, typen en foutafhandeling

Wat is Non-Fatal Error

Non-Fatal Error — is een uitzondering of foutieve toestand die niet leidt tot beëindiging van het proces. De applicatie blijft werken, maar kan zich in een onjuiste toestand bevinden: gegevens zijn niet geladen, verzoek is niet verzonden, interface-element is niet weergegeven. De gebruiker merkt de fout niet op of ziet een bericht en gaat verder met het gebruik van de applicatie.

Belangrijkste kenmerken

Een niet-fatale fout laat het programma altijd een weg naar herstel. De foutafhandelaar kan alternatieve gegevens bieden, de operatie opnieuw proberen of een interface-placeholder tonen. De hoofdtaak is het voorkomen van een crash en het behouden van de gebruikerservaring op een aanvaardbaar niveau. De ontwikkelaar moet expliciet een herstelscenario voorzien in elk catch-blok.

Rol in applicatiestabiliteit

Volgens gegevens van Instabug 2024 verwijdert 65% van de gebruikers een applicatie na twee mislukte interacties. Non-fatal fouten die onopgemerkt blijven, stapelen zich op en verlagen de algemene kwaliteit. Systematisch loggen en corrigeren van niet-fatale fouten is een directe weg naar hogere retentie en betere gebruikersbeoordelingen in app-winkels.

Typen niet-fatale fouten

Netwerkfouten — het meest voorkomende type non-fatal fouten in mobiele applicaties. Time-out van verbinding, netwerkverlies, onjuiste serverstatuscode — al deze situaties worden opgevangen en verwerkt zonder crash. De gebruiker krijgt een bericht over de onbeschikbaarheid van de dienst met een voorstel om het opnieuw te proberen. Voor netwerkfouten is het patroon retry met exponentiële vertraging typerend.

Gegevensvalidatiefouten

Onjuist formaat van serverantwoord, ontbrekend verplicht veld, onjuist gegevenstype — parseringsfouten zijn niet-fataal als de applicatie onjuiste gegevens correct verwerkt. De typische aanpak is het gebruik van standaard reservewaarden en het loggen van de parseringsfout met de context van het verzoek voor latere analyse op de server.

UI-renderfouten

Problemen met het laden van afbeeldingen, onjuiste lettertypen, layoutfouten — ze zijn allemaal niet fataal, maar verslechteren de gebruikerservaring. Placeholder-afbeeldingen en fallback-waarden voorkomen lege schermen en maken fouten minder zichtbaar. In React Native wordt voor UI-fouten Error Boundary gebruikt met weergave van een reservecomponent.

Fouten in bedrijfslogica en toestand

Fouten in berekeningen, toestandsconflicten, onjuiste overgangen tussen schermen — logische fouten leiden vaak niet tot een crash, maar wel tot onjuist gedrag van de applicatie. Ze zijn moeilijker te detecteren zonder systematisch loggen en monitoring, omdat ze geen crashrapport genereren en onopgemerkt blijven tot een gebruikersklacht.

Non-Fatal Error vs Fatal Error: vergelijking

Non-Fatal Error verschilt van fatal doordat het programma de mogelijkheid blijft houden om door te werken. Fatal error — is een toestand waaruit de applicatie niet kan herstellen: dereferentie van een null-pointer, stack-overflow, geheugengebrek. Een non-fatal fout kan worden opgevangen, verwerkt en de uitvoering kan worden voortgezet, terwijl fatal error een herstart van de applicatie vereist.

De grens tussen non-fatal en fatal kan afhangen van de implementatie. Een netwerk-time-out wordt in de ene applicatie als non-fatal verwerkt (herhalen van het verzoek na 1–2 seconden), in een andere kan het fataal zijn (crash bij afwezigheid van een afhandelaar). Kwalitatieve foutafhandeling verandert potentieel fatale situaties in niet-fatale, waardoor de stabiliteit van de applicatie toeneemt. Het ontwerpen van een foutafhandelingssysteem is een van de belangrijkste architecturale taken bij de ontwikkeling van een mobiele applicatie met hoge betrouwbaarheidseisen. Het ingebouwde monitoringsysteem stelt het team in staat niet-fatale fouten snel te detecteren en te verhelpen voordat ze een aanzienlijk aantal gebruikers beïnvloeden.

Loggen van non-fatal fouten

Firebase Crashlytics — het belangrijkste hulpmiddel voor het loggen van niet-fatale fouten in mobiele applicaties. De methode recordException maakt het mogelijk een non-fatal uitzondering vast te leggen met volledige stacktrace en uitvoeringscontext, zonder de werking van de applicatie te onderbreken. In tegenstelling tot crashrapporten kan recordException op elke plek in de code worden aangeroepen om opgevangen uitzonderingen te loggen.

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: gebruiken reservegegevens
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// Loggen met gebruikerssleutels
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry — een alternatief voor Crashlytics met meer gedetailleerde diagnose van non-fatal fouten. De Sentry SDK biedt de methode captureException, die de details van de uitzondering naar de server stuurt. Het belangrijkste voordeel van Sentry is het groeperen van vergelijkbare non-fatal fouten in één issue, analyse van de herhalingsfrequentie en uitvoeringscontext in de vorm van breadcrumbs — de reeks gebruikersacties voorafgaand aan de fout.

Criteria voor het loggen van non-fatal fouten

Niet alle non-fatal fouten hoeven te worden gelogd. Verwachte toestanden — netwerkuitval bij afwezigheid van verbinding — kunnen selectief worden gelogd. Onverwachte fouten — NullPointerException in verwerkte code, onjuist gegevensformaat, logic error — moeten altijd worden gelogd. Elk team bepaalt de significantiedrempel: gemiddeld worden 10 tot 20 unieke non-fatal fouten per 1000 gebruikers per dag als normaal beschouwd. Het is belangrijk om waarschuwingen in te stellen op een plotselinge toename van het aantal non-fatal fouten — dit kan wijzen op problemen met een nieuwe API-versie of regressie na een release.

Verwerking van non-fatal fouten in code

Het basismechanisme voor verwerking — try-catch, dat de uitzondering opvangt en de herstelcode uitvoert. Voor netwerkoperaties is het typische patroon het herhalen van het verzoek met exponentiële vertraging (retry with backoff). Voor parseringsfouten — het gebruik van standaard reservewaarden en het loggen van de context voor latere analyse aan de serverzijde.

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-typen — een alternatieve benadering zonder uitzonderingen. De functie retourneert een sealed class Result met varianten Success en Failure. De aanroepende code verwerkt beide varianten expliciet, wat niet-afgehandelde fouten elimineert. Result-typen zijn populair in Kotlin (Result in de standaardbibliotheek) en Swift (Result) voor expliciete verwerking van non-fatal toestanden op typeniveau.

Fallback-strategieën voor non-fatal fouten

Voor elk type non-fatal fout moet een herstelstrategie worden voorzien: laden van gecachte gegevens bij een netwerkfout, gebruik van standaardwaarden bij een parseringsfout, opnieuw initialiseren van de component bij een UI-fout. Een goede praktijk is het tonen van een toast of snackbar met een foutmelding aan de gebruiker, maar niet het volledig blokkeren van de interactie met de applicatie. Het is belangrijk onderscheid te maken tussen herstelbare (recoverable) en niet-herstelbare fouten — voor de laatste zal de herstelstrategie anders zijn, bijvoorbeeld het voorstel om het scherm opnieuw te starten of gegevens te wissen. Het cachen van de vorige succesvolle toestand blijkt vaak de eenvoudigste en meest effectieve manier om non-fatal fouten op mobiele platforms te verwerken.