Non-Fatal Error mobilalkalmazásokban — lényeg, típusok és hibakezelés

Mi az a Non-Fatal Error

Non-Fatal Error — olyan kivétel vagy hibás állapot, amely nem okozza a folyamat megszakítását. Az alkalmazás tovább működik, de hibás állapotban lehet: az adatok nem töltődtek be, a kérés nem küldődött el, a felületi elem nem jelent meg. A felhasználó vagy nem veszi észre a hibát, vagy lát egy üzenetet és folytatja az alkalmazás használatát.

Fő jellemzők

A nem végzetes hiba mindig hagy a programnak helyreállítási utat. A hibakezelő alternatív adatokat kínálhat, megismételheti a műveletet, vagy megjeleníthet egy felületi helyőrzőt. A fő feladat megakadályozni az összeomlást és a felhasználói élményt elfogadható szinten tartani. A fejlesztőnek minden catch blokkban kifejezetten elő kell látnia egy helyreállítási forgatókönyvet.

Szerep az alkalmazások stabilitásában

Az Instabug 2024 adatai szerint a felhasználók 65%-a törli az alkalmazást két sikertelen interakció után. A figyelmen kívül hagyott non-fatal hibák felhalmozódnak és csökkentik az általános működési minőséget. A nem végzetes hibák szisztematikus naplózása és javítása közvetlen út a megtartás növeléséhez és a felhasználói értékelések javításához az alkalmazásboltokban.

Nem végzetes hibák típusai

Hálózati hibák — a non-fatal hibák leggyakoribb típusa mobilalkalmazásokban. Kapcsolódási időtúllépés, hálózat elvesztése, hibás szerver állapotkód — ezek a helyzetek mind elkaphatók és kezelhetők összeomlás nélkül. A felhasználó számára üzenet jelenik meg a szolgáltatás elérhetetlenségéről, újrapróbálkozási javaslattal. A hálózati hibákra jellemző az exponenciális késleltetésű újrapróbálkozási minta (retry).

Adatérvényesítési hibák

Hibás szerverválasz formátum, kötelező mező hiánya, hibás adattípus — elemzési hibák nem végzetesek, ha az alkalmazás helyesen kezeli a hibás adatokat. A tipikus megközelítés az alapértelmezett tartalékértékek használata és az elemzési hiba naplózása a kérés kontextusával a későbbi szerveroldali elemzéshez.

UI-megjelenítési hibák

Problémák a képek betöltésével, hibás betűtípusok, layout-hibák — ezek egyike sem végzetes, de rontja a felhasználói élményt. Helyőrző képek és fallback értékek segítenek elkerülni az üres képernyőket, és kevésbé észrevehetővé teszik a hibákat. A React Native-ben az UI-hibákhoz Error Boundary-t használnak tartalék komponens megjelenítésével.

Üzleti logikai és állapot hibák

Számítási hibák, állapot-összeférhetetlenségek, hibás képernyőátmenetek — logikai hibák gyakran nem vezetnek összeomláshoz, de az alkalmazás hibás viselkedését okozzák. Nehezebb észlelni őket szisztematikus naplózás és monitorozás nélkül, mert nem hoznak létre összeomlási jelentést, és észrevétlenek maradnak a felhasználói panaszig.

Non-Fatal Error vs Fatal Error: összehasonlítás

Non-Fatal Error abban különbözik a fatal-tól, hogy lehetőséget hagy a programnak a munka folytatására. A fatal error olyan állapot, amelyből az alkalmazás nem tud helyreállni: null pointer dereferálása, verem túlcsordulása, memóriahiány. A non-fatal hiba elkapható, kezelhető és a végrehajtás folytatható, míg a fatal error az alkalmazás újraindítását igényli.

A non-fatal és fatal közötti határ függhet a megvalósítástól. Hálózati időtúllépés az egyik alkalmazásban non-fatal-ként van kezelve (kérés megismétlése 1–2 másodperc után), egy másikban lehet fatális (összeomlás kezelő hiányában). A minőségi hibakezelés a potenciálisan fatális helyzeteket nem végzetessé alakítja, növelve az alkalmazás stabilitását. A hibakezelő rendszer tervezése az egyik legfontosabb építészeti feladat a magas megbízhatósági követelményekkel rendelkező mobilalkalmazás fejlesztése során. A beépített monitorozó rendszer lehetővé teszi a csapat számára a nem végzetes hibák gyors észlelését és kijavítását, mielőtt azok jelentős számú felhasználót érintenének.

Non-fatal hibák naplózása

Firebase Crashlytics — a nem végzetes hibák naplózásának fő eszköze mobilalkalmazásokban. A recordException metódus lehetővé teszi egy non-fatal kivétel rögzítését teljes stack trace-szel és végrehajtási kontextussal, anélkül hogy megszakítaná az alkalmazás működését. Az összeomlási jelentésektől eltérően a recordException a kód bármely pontján meghívható az elkapott kivételek naplózására.

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: tartalék adatokat használunk
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// Naplózás felhasználói kulcsokkal
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry — alternatíva a Crashlytics-hez, részletesebb non-fatal hiba diagnosztikával. A Sentry SDK captureException metódust biztosít, amely elküldi a kivétel részleteit a szerverre. A Sentry kulcsfontosságú előnye a hasonló non-fatal hibák egyetlen issue-ba csoportosítása, az ismétlődési gyakoriság elemzése és a végrehajtási kontextus breadcrumbs formájában — a felhasználói műveletek sorrendje a hiba előtt.

A non-fatal hibák naplózásának kritériumai

Nem minden non-fatal hibát kell naplózni. Várható állapotok — hálózati hiba kapcsolat hiányában — szelektíven naplózhatók. Váratlan hibák — NullPointerException a kezelt kódban, hibás adatformátum, logic error — mindig naplózandók. Minden csapat meghatározza a jelentőségi küszöböt: átlagosan 10–20 egyedi non-fatal hiba 1000 felhasználónként naponta normálisnak tekinthető. Fontos riasztásokat beállítani a non-fatal hibák számának hirtelen növekedésére — ez jelezheti az API új verziójával kapcsolatos problémákat vagy a kiadás utáni regressziót.

Non-fatal hibák kezelése kódban

Az alapvető kezelési mechanizmus — try-catch, amely elkapja a kivételt és végrehajtja a helyreállítási kódot. Hálózati műveletek esetén a tipikus minta a kérés megismétlése exponenciális késleltetéssel (retry with backoff). Elemzési hibák esetén — alapértelmezett tartalékértékek használata és a kontextus naplózása a későbbi szerveroldali elemzéshez.

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 típusok — alternatív megközelítés kivételek nélkül. A függvény egy sealed class Result-ot ad vissza Success és Failure változatokkal. A hívó kód mindkét változatot kifejezetten kezeli, ami kiküszöböli a kezeletlen hibákat. A Result típusok népszerűek Kotlinban (Result a szabványos könyvtárban) és Swiftben (Result) a non-fatal állapotok kifejezett kezelésére típus szinten.

Fallback stratégiák non-fatal hibákhoz

Minden non-fatal hibatípushoz helyreállítási stratégiát kell előirányozni: gyorsítótárazott adatok betöltése hálózati hiba esetén, alapértelmezett értékek használata elemzési hiba esetén, komponens újrainicializálása UI hiba esetén. Jó gyakorlat egy toast vagy snackbar megjelenítése a hibaüzenettel, de nem az alkalmazással való interakció teljes blokkolása. Fontos különbséget tenni a helyreállítható (recoverable) és a nem helyreállítható hibák között — az utóbbiaknál a helyreállítási stratégia más lesz, például a képernyő újraindításának vagy az adatok törlésének javaslata. Az előző sikeres állapot gyorsítótárazása gyakran a legegyszerűbb és leghatékonyabb módja a non-fatal hibák kezelésének mobil platformokon.