Zpracování chyb v mobilním vývoji: co to je, jaké techniky a jak to organizovat

Zpracování chyb v iOS: Do-Catch, Throw, Guard Let

Zpracování chyb ve Swiftu je postaveno na čtyřech klíčových mechanismech: do-catch, throws, guard let a if-let. Na rozdíl od mnoha jazyků Swift nepovoluje nezachycené výjimky — každá chyba musí být explicitně ošetřena nebo deklarována prostřednictvím throws. Zpracování chyb je kritická dovednost pro mobilní vývoj, která přímo ovlivňuje stabilitu aplikace.

Do-Catch a Throw

do-catch je standardní blok pro volání funkcí označených throws. Uvnitř do je funkce volána s try, a pokud vyvolá chybu, řízení přechází na catch. Různé typy chyb lze zpracovat pomocí pattern matching. Pokud chyba není ošetřena, propaguje se nahoru zásobníkem (Error Propagation). Pro efektivní zpracování chyb v iOS používejte do-catch jako primární mechanismus.

Throw je deklarován v signatuře funkce: func fetchData() throws -> Data. To znamená, že volající kód musí chybu ošetřit pomocí try, try? nebo try!. try? převede chybu na nil, try! způsobí pád při chybě (používejte pouze pokud jste si jisti úspěchem). Zpracování chyb pomocí throw je povinná praxe ve Swiftu.

Optional/Nullable a Guard Let

Guard let je konstrukce pro předčasný odchod z funkce, pokud je hodnota nil. Na rozdíl od if-let, guard let vyžaduje odchod (return, throw, break) ve větvi else. To činí kód plošším a čitelnějším — bez vnořených bloků if. Pokud optional nemůže být nil — použijte force unwrap (!), pouze když jste si naprosto jisti. V mobilní aplikaci guard let pomáhá předcházet pádům při zpracování volitelných hodnot.

Optional Chaining (user?.address?.city) a nil-coalescing (??) jsou syntaktický cukr pro práci s optional bez rozbalování. V IT Sectr používáme guard let pro validaci vstupních parametrů API a vyžadujeme, aby se tým vyhýbal force unwrap bez explicitního komentáře. Zpracovatel chyb na každé úrovni chrání před neočekávanými selháními.

Zpracování chyb v Android: Try-Catch, Elvis, Sealed Class

Kotlin je primární jazyk pro vývoj Android. Dědí try-catch z Javy, ale přidává bezpečnější alternativy: operátor elvis, require, check a sealed class. Zpracování chyb v Kotlinu je postaveno na kombinaci těchto mechanismů. Na rozdíl od Swiftu, Kotlin nevyžaduje ošetření kontrolovaných výjimek (všechny výjimky jsou nekontrolované). Pro zpracování chyb v mobilních aplikacích na Androidu používejte sealed class jako primární vzor.

Try-Catch a operátor Elvis

Try-catch v Kotlinu funguje jako výraz — vrací hodnotu. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. To zkracuje kód. Operátor Elvis (?:) je analog nil-coalescing pro nullable typy: val name = user?.name ?: "Guest". Pro zpracování chyb v mobilních aplikacích je try-catch jako výraz nejvýstižnějším přístupem.

Sealed class je mocný nástroj pro modelování stavů úspěchu a chyby. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Při použití ve výrazu when kompilátor kontroluje úplnost větví. Zpracování chyb prostřednictvím sealed class zaručuje, že žádný stav nezůstane neošetřen.

// Sealed class + try-catch — typický vzor pro 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}")
    }
}

V příkladu sealed class NetworkResult modeluje dva stavy: úspěch s daty a chybu se zprávou. Funkce fetchUser vrací výsledek v každém případě a volající kód zpracovává obě větve pomocí when. To eliminuje možnost neošetřené chyby. Zpracování chyb prostřednictvím sealed class je standardem pro vývoj Android v IT Sectr.

Zpracování chyb v Kotlin: Result a Either

Result je vestavěný typ Kotlinu pro reprezentaci výsledku operace, která může selhat. Vynucuje zpracování úspěchu a neúspěchu pomocí fold, getOrThrow nebo map. Result je užitečný v asynchronních řetězcích (coroutines). Zpracování chyb pomocí Result je standardem pro mobilní vývoj v Kotlinu.

Result vs Either

Either je funkcionální typ z knihovny Arrow, který umožňuje vrátit hodnotu jednoho ze dvou typů (Left — chyba, Right — úspěch). Na rozdíl od Result může Either obsahovat jakýkoli uživatelem definovaný typ chyby. Pro jednoduché projekty stačí vestavěný Result; pro složité projekty použijte Either z Arrow. Výběr nástroje pro zpracování chyb závisí na složitosti projektu.

Propagace chyb

Propagace chyb je mechanismus, při kterém se chyba šíří nahoru zásobníkem volání, dokud není ošetřena. V Kotlinu k tomu dochází ve výchozím nastavení (nekontrolované výjimky). Ve Swiftu se to týká pouze funkcí označených throws. U Result a Either se chyby nešíří — zůstávají v typu a musíte je ošetřit. To činí zpracování chyb v mobilních aplikacích bezpečnějším.

Tabulka ukazuje klíčové rozdíly. iOS vyžaduje explicitní deklaraci chyb (throws), což činí kód bezpečnějším, ale rozvláčnějším. Android se spoléhá na disciplínu vývojáře. V IT Sectr používáme sealed class pro Android a throws pro iOS — to je nejlepší praxe obou platforem pro zpracování chyb v mobilních aplikacích.

Hlášení pádů: Crashlytics a Sentry

Hlášení pádů je systém pro sběr a analýzu pádů aplikace. Hlášení pádů je nezbytnou součástí zpracování chyb v produkci. Bez něj se o problémech dozvíte od uživatelů, což je pro produkci nepřijatelné. Dva hlavní nástroje: Firebase Crashlytics (zdarma) a Sentry (zdarma pro základní použití). Pro zpracování chyb v mobilních aplikacích vždy implementujte hlášení pádů od prvního vydání.

Firebase Crashlytics

Crashlytics je součástí Firebase. Automaticky shromažďuje pády, seskupuje je podle zásobníku volání a zobrazuje počet postižených uživatelů. Podporuje protokolování nefatálních chyb prostřednictvím recordException(). Integrace: přidejte SDK do build.gradle (Android) nebo Podfile (iOS). Crashlytics je nejlepší bezplatný nástroj pro zpracování chyb při startu projektu.

Sentry

Sentry je multiplatformní systém monitorování chyb. Na rozdíl od Crashlytics poskytuje Sentry podrobné sledování (breadcrumbs), monitorování výkonu a podporu React Native. Umožňuje zobrazit stav aplikace v okamžiku chyby. IT Sectr doporučuje Sentry pro projekty, které potřebují plnou kontrolu nad zpracováním chyb v mobilním vývoji.

Error Boundary v React Native

Error Boundary je React komponenta, která zachycuje chyby JavaScriptu ve stromu podřízených komponent a zobrazuje náhradní uživatelské rozhraní, čímž zabraňuje úplnému pádu aplikace. Error Boundary je klíčovou komponentou pro zpracování chyb v React Native. Používejte error boundaries pro kritické obrazovky a navigaci. Zpracování chyb v mobilních aplikacích na React Native vyžaduje správné nastavení Error Boundary na nejvyšší úrovni.

Implementace Error Boundary

Error Boundary je vytvořen pomocí componentDidCatch(error, errorInfo) nebo static getDerivedStateFromError(error). Nezachycuje chyby v asynchronním kódu (setTimeout, requestAnimationFrame), renderování na serveru nebo nativních chybách (Native Modules). Pro protokolování použijte SDK pro hlášení pádů uvnitř componentDidCatch. Error Boundary je jednoduchý, ale účinný zpracovatel chyb pro vrstvu uživatelského rozhraní.

Fatální a nefatální chyby

Fatální chyba je neošetřená výjimka, která způsobí pád aplikace. Nefatální chyba je výjimka, kterou jste zachytili a ošetřili, ale která ukazuje na problém v kódu. Nefatální chyby jsou protokolovány prostřednictvím Crashlytics/Sentry a pomáhají najít chyby dříve, než se stanou fatálními. Fatální i nefatální chyby vyžadují správné zpracování chyb v mobilním vývoji.