Non-Fatal Error v mobilních aplikacích — podstata, typy a zpracování chyb

Co je Non-Fatal Error

Non-Fatal Error — je výjimka nebo chybový stav, který nezpůsobuje ukončení procesu. Aplikace nadále funguje, ale může být v nesprávném stavu: data se nenačetla, požadavek se neodeslal, prvek rozhraní se nezobrazil. Uživatel buď chybu nezaznamená, nebo vidí zprávu a pokračuje v používání aplikace.

Klíčové znaky

Nefatální chyba vždy ponechává programu cestu k obnovení. Zpracovatel chyb může nabídnout alternativní data, zopakovat operaci nebo zobrazit zástupný prvek rozhraní. Hlavním úkolem je zabránit crashi a udržet uživatelský zážitek na přijatelné úrovni. Vývojář musí výslovně předvídat scénář obnovení v každém bloku catch.

Role ve stabilitě aplikací

Podle údajů Instabug 2024 65 % uživatelů odstraňuje aplikaci po dvou neúspěšných interakcích. Non-fatal chyby ponechané bez povšimnutí se hromadí a snižují celkovou kvalitu provozu. Systematické logování a opravování nefatálních chyb je přímou cestou ke zvýšení retence a zlepšení uživatelských hodnocení v obchodech s aplikacemi.

Typy nefatálních chyb

Síťové chyby — nejčastější typ non-fatal chyb v mobilních aplikacích. Časový limit připojení, ztráta sítě, nesprávný stavový kód serveru — všechny tyto situace jsou zachyceny a zpracovány bez crashi. Uživateli se zobrazí zpráva o nedostupnosti služby s návrhem opakování. Pro síťové chyby je typický vzor retry s exponenciálním zpožděním.

Chyby validace dat

Nesprávný formát odpovědi serveru, chybějící povinné pole, nesprávný typ dat — chyby parsování jsou nefatální, pokud aplikace správně zpracovává nesprávná data. Typickým přístupem je použití výchozích záložních hodnot a logování chyby parsování s kontextem požadavku pro pozdější analýzu na serveru.

Chyby vykreslování UI

Problémy s načítáním obrázků, nesprávná písma, chyby v rozložení — všechny nejsou fatální, ale zhoršují dojem uživatele. Zástupné obrázky a fallback hodnoty umožňují vyhnout se prázdným obrazovkám a činí chyby méně viditelnými. V React Native se pro UI chyby používá Error Boundary se zobrazením záložní komponenty.

Chyby business logiky a stavu

Chyby ve výpočtech, nesoulad stavů, nesprávné přechody mezi obrazovkami — logické chyby často nevedou k crashi, ale vedou k nesprávnému chování aplikace. Je obtížnější je odhalit bez systematického logování a monitorování, protože nevytvářejí crash report a zůstávají nepovšimnuty až do stížnosti uživatele.

Non-Fatal Error vs Fatal Error: srovnání

Non-Fatal Error se liší od fatal tím, že ponechává programu možnost pokračovat v práci. Fatal error — je stav, ze kterého se aplikace nemůže zotavit: dereference null ukazatele, přetečení zásobníku, nedostatek paměti. Non-fatal chybu lze zachytit, zpracovat a pokračovat v provádění, zatímco fatal error vyžaduje restart aplikace.

Hranice mezi non-fatal a fatal může záviset na implementaci. Časový limit sítě je v jedné aplikaci zpracováván jako non-fatal (opakování požadavku po 1–2 sekundách), v jiné může být fatální (crash při absenci zpracovatele). Kvalitní zpracování chyb přeměňuje potenciálně fatální situace na nefatální, čímž zvyšuje stabilitu aplikace. Navrhování systému zpracování chyb je jedním z klíčových architektonických úkolů při vývoji mobilní aplikace s vysokými požadavky na spolehlivost. Vestavěný monitorovací systém umožňuje týmu rychle odhalovat a odstraňovat nefatální chyby dříve, než ovlivní významný počet uživatelů.

Logování non-fatal chyb

Firebase Crashlytics — hlavní nástroj pro logování nefatálních chyb v mobilních aplikacích. Metoda recordException umožňuje zaznamenat non-fatal výjimku s úplným stack trace a kontextem provádění, aniž by došlo k přerušení činnosti aplikace. Na rozdíl od crash reportů lze recordException volat na libovolném místě kódu pro logování zachycených výjimek.

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: používáme záložní data
        Crashlytics.recordException(e)
        showFallbackContent()
    }
}

// Logování s uživatelskými klíči
Crashlytics.setCustomKey("screen", "Profile")
Crashlytics.setCustomKey("api_version", "v3")

Sentry — alternativa k Crashlytics s podrobnější diagnostikou non-fatal chyb. Sentry SDK poskytuje metodu captureException, která odesílá podrobnosti výjimky na server. Klíčovou výhodou Sentry je seskupování podobných non-fatal chyb do jednoho issue, analýza frekvence opakování a kontext provádění ve formě breadcrumbs — posloupnosti akcí uživatele před chybou.

Kritéria logování non-fatal chyb

Ne všechny non-fatal chyby je třeba logovat. Očekávané stavy — výpadek sítě při absenci připojení — lze logovat selektivně. Neočekávané chyby — NullPointerException ve zpracovaném kódu, nesprávný formát dat, logic error — by měly být logovány vždy. Každý tým určuje práh významnosti: v průměru 10 až 20 unikátních non-fatal chyb na 1000 uživatelů denně je považováno za normu. Důležité je nastavit alerty na prudký nárůst počtu non-fatal chyb — to může naznačovat problémy s novou verzí API nebo regresi po vydání.

Zpracování non-fatal chyb v kódu

Základním mechanismem zpracování je try-catch, který zachycuje výjimku a provádí kód obnovení. Pro síťové operace je typickým vzorem opakování požadavku s exponenciálním zpožděním (retry with backoff). Pro chyby parsování — použití výchozích záložních hodnot a logování kontextu pro pozdější analýzu na straně serveru.

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)
}

Typy Result — alternativní přístup bez výjimek. Funkce vrací sealed class Result s variantami Success a Failure. Volající kód zpracovává obě varianty explicitně, což eliminuje neošetřené chyby. Typy Result jsou populární v Kotlin (Result ve standardní knihovně) a Swift (Result) pro explicitní zpracování non-fatal stavů na úrovni typů.

Fallback strategie pro non-fatal chyby

Pro každý typ non-fatal chyby je třeba předvídat strategii obnovení: načtení dat z cache při síťové chybě, použití výchozích hodnot při chybě parsování, opětovná inicializace komponenty při UI chybě. Dobrou praxí je zobrazení toastu nebo snackbaru se zprávou o chybě uživateli, ale ne úplné blokování interakce s aplikací. Důležité je rozlišovat obnovitelné (recoverable) a neobnovitelné chyby — pro druhé bude strategie obnovení jiná, například návrh na restartování obrazovky nebo vymazání dat. Ukládání předchozího úspěšného stavu do cache se často ukazuje jako nejjednodušší a nejefektivnější způsob zpracování non-fatal chyb na mobilních platformách.