Gestionarea erorilor în dezvoltarea mobilă: ce este, ce tehnici și cum să organizezi

Gestionarea erorilor în iOS: Do-Catch, Throw, Guard Let

Gestionarea erorilor în Swift se bazează pe patru mecanisme cheie: do-catch, throws, guard let și if-let. Spre deosebire de multe limbaje, Swift nu permite excepții neprinse — fiecare eroare trebuie tratată explicit sau declarată prin throws. Gestionarea erorilor este o abilitate critică pentru dezvoltarea mobilă, având un impact direct asupra stabilității aplicației.

Do-Catch și Throw

do-catch este blocul standard pentru apelarea funcțiilor marcate cu throws. În interiorul do, o funcție este apelată cu try, iar dacă aruncă o eroare, controlul trece la catch. Diferite tipuri de erori pot fi tratate prin pattern matching. Dacă o eroare nu este tratată, se propagă în sus pe stivă (Error Propagation). Pentru o gestionare eficientă a erorilor în iOS, folosește do-catch ca mecanism principal.

Throw este declarat în semnătura funcției: func fetchData() throws -> Data. Aceasta înseamnă că codul apelant trebuie să trateze eroarea prin try, try? sau try!. try? convertește eroarea în nil, try! provoacă un crash la eroare (folosește doar dacă ești sigur de succes). Gestionarea erorilor prin throw este o practică obligatorie în Swift.

Optional/Nullable și Guard Let

Guard let este o construcție pentru ieșirea timpurie dintr-o funcție dacă valoarea este nil. Spre deosebire de if-let, guard let necesită o ieșire (return, throw, break) în ramura else. Acest lucru face codul mai plat și mai lizibil — fără blocuri if imbricate. Dacă un optional nu poate fi nil — folosește force unwrap (!), doar când ești absolut sigur. Într-o aplicație mobilă, guard let ajută la evitarea crash-urilor la tratarea valorilor opționale.

Optional Chaining (user?.address?.city) și nil-coalescing (??) sunt zahăr sintactic pentru lucrul cu optionals fără despachetare. La IT Sectr, folosim guard let pentru validarea parametrilor de intrare API și impunem echipei să evite force unwrap fără un comentariu explicit. Un gestionar de erori la fiecare nivel protejează împotriva defecțiunilor neașteptate.

Gestionarea erorilor în Android: Try-Catch, Elvis, Sealed Class

Kotlin este limbajul principal pentru dezvoltarea Android. Moștenește try-catch din Java, dar adaugă alternative mai sigure: operatorul elvis, require, check și sealed class. Gestionarea erorilor în Kotlin se bazează pe o combinație a acestor mecanisme. Spre deosebire de Swift, Kotlin nu necesită tratarea excepțiilor verificate (toate excepțiile sunt neverificate). Pentru gestionarea erorilor în aplicațiile mobile pe Android, folosește sealed class ca model principal.

Try-Catch și operatorul Elvis

Try-catch în Kotlin funcționează ca o expresie — returnează o valoare. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Acest lucru reduce codul. Operatorul Elvis (?:) este un analog al nil-coalescing pentru tipurile nullable: val name = user?.name ?: "Guest". Pentru gestionarea erorilor în aplicațiile mobile, try-catch ca expresie este cea mai concisă abordare.

Sealed class este un instrument puternic pentru modelarea stărilor de succes și eroare. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Când este utilizată într-o expresie when, compilatorul verifică exhaustivitatea ramurilor. Gestionarea erorilor prin sealed class garantează că nicio stare nu rămâne netratată.

// Sealed class + try-catch — model tipic pentru 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}")
    }
}

În exemplu, sealed class NetworkResult modelează două stări: succes cu date și eroare cu mesaj. Funcția fetchUser returnează un rezultat în orice caz, iar codul apelant tratează ambele ramuri prin when. Aceasta elimină posibilitatea unei erori netratate. Gestionarea erorilor prin sealed class este standardul pentru dezvoltarea Android la IT Sectr.

Gestionarea erorilor în Kotlin: Result și Either

Result este un tip încorporat în Kotlin pentru a reprezenta rezultatul unei operațiuni care poate eșua. Forțează tratarea succesului și eșecului prin fold, getOrThrow sau map. Result este util în lanțuri asincrone (coroutines). Gestionarea erorilor cu Result este un standard pentru dezvoltarea mobilă în Kotlin.

Result vs Either

Either este un tip funcțional din biblioteca Arrow care permite returnarea unei valori dintr-unul din două tipuri (Left — eroare, Right — succes). Spre deosebire de Result, Either poate conține orice tip de eroare definit de utilizator. Pentru proiecte simple, Result încorporat este suficient; pentru proiecte complexe, folosește Either din Arrow. Alegerea instrumentului de gestionare a erorilor depinde de complexitatea proiectului.

Propagarea erorilor

Propagarea erorilor este un mecanism prin care o eroare se propagă în sus pe stiva de apeluri până când este tratată. În Kotlin, aceasta se întâmplă implicit (excepții neverificate). În Swift, se aplică doar funcțiilor marcate cu throws. Cu Result și Either, erorile nu se propagă — rămân în tip și trebuie să le tratezi. Acest lucru face gestionarea erorilor în aplicațiile mobile mai sigură.

Tabelul arată diferențele cheie. iOS necesită declararea explicită a erorilor (throws), făcând codul mai sigur, dar mai verbose. Android se bazează pe disciplina dezvoltatorului. La IT Sectr, folosim sealed class pentru Android și throws pentru iOS — aceasta este cea mai bună practică a ambelor platforme pentru gestionarea erorilor în aplicațiile mobile.

Raportarea crash-urilor: Crashlytics și Sentry

Raportarea crash-urilor este un sistem de colectare și analiză a crash-urilor aplicației. Raportarea crash-urilor este o parte esențială a gestionării erorilor în producție. Fără ea, afli despre probleme de la utilizatori, ceea ce este inacceptabil pentru producție. Două instrumente principale: Firebase Crashlytics (gratuit) și Sentry (gratuit pentru utilizare de bază). Pentru gestionarea erorilor în aplicațiile mobile, implementează întotdeauna raportarea crash-urilor de la prima lansare.

Firebase Crashlytics

Crashlytics face parte din Firebase. Colectează automat crash-urile, le grupează după stiva de apeluri și arată numărul de utilizatori afectați. Suportă înregistrarea erorilor non-fatale prin recordException(). Integrare: adaugă SDK-ul în build.gradle (Android) sau Podfile (iOS). Crashlytics este cel mai bun instrument gratuit pentru gestionarea erorilor la începutul unui proiect.

Sentry

Sentry este un sistem de monitorizare a erorilor cross-platform. Spre deosebire de Crashlytics, Sentry oferă urmărire detaliată (breadcrumbs), monitorizare a performanței și suport pentru React Native. Permite vizualizarea stării aplicației în momentul erorii. IT Sectr recomandă Sentry pentru proiectele care au nevoie de control complet asupra gestionării erorilor în dezvoltarea mobilă.

Error Boundary în React Native

Error Boundary este o componentă React care prinde erori JavaScript în arborele componentelor copil și afișează o interfață de rezervă, prevenind un crash complet al aplicației. Error Boundary este o componentă cheie pentru gestionarea erorilor în React Native. Folosește error boundaries pentru ecrane critice și navigare. Gestionarea erorilor în aplicațiile mobile pe React Native necesită o configurare adecvată a Error Boundary la nivelul superior.

Implementarea Error Boundary

Error Boundary este creat prin componentDidCatch(error, errorInfo) sau static getDerivedStateFromError(error). Nu prinde erori în cod asincron (setTimeout, requestAnimationFrame), randare pe server sau erori native (Native Modules). Pentru înregistrare, folosește SDK-ul de raportare a crash-urilor în interiorul componentDidCatch. Error Boundary este un gestionar de erori simplu, dar eficient pentru stratul de interfață.

Erori fatale vs non-fatale

Eroare fatală este o excepție netratată care provoacă un crash al aplicației. Eroare non-fatală este o excepție pe care ai prins-o și ai tratat-o, dar indică o problemă în cod. Erorile non-fatale sunt înregistrate prin Crashlytics/Sentry și ajută la găsirea bug-urilor înainte ca acestea să devină fatale. Atât erorile fatale, cât și cele non-fatale necesită o gestionare adecvată a erorilor în dezvoltarea mobilă.