Obrada grešaka u mobilnom razvoju: šta je to, koje tehnike i kako organizovati

Obrada grešaka u iOS-u: Do-Catch, Throw, Guard Let

Obrada grešaka u Swift-u se zasniva na četiri ključna mehanizma: do-catch, throws, guard let i if-let. Za razliku od mnogih jezika, Swift ne dozvoljava neuhvaćene izuzetke — svaka greška mora biti eksplicitno obrađena ili deklarísana putem throws. Obrada grešaka je kritična veština za mobilni razvoj, koja direktno utiče na stabilnost aplikacije.

Do-Catch i Throw

do-catch je standardni blok za pozivanje funkcija označenih sa throws. Unutar do, funkcija se poziva sa try, i ako baci grešku, kontrola prelazi na catch. Različiti tipovi grešaka mogu se obrađivati putem pattern matching-a. Ako greška nije obrađena, propagira se naviše na steku (Error Propagation). Za efikasnu obradu grešaka u iOS-u, koristite do-catch kao primarni mehanizam.

Throw se deklariše u potpisu funkcije: func fetchData() throws -> Data. To znači da pozivajući kod mora obraditi grešku putem try, try? ili try!. try? pretvara grešku u nil, try! izaziva pad pri grešci (koristite samo ako ste sigurni u uspeh). Obrada grešaka putem throws je obavezna praksa u Swift-u.

Optional/Nullable i Guard Let

Guard let je konstrukcija za rani izlazak iz funkcije ako je vrednost nil. Za razliku od if-let, guard let zahteva izlaz (return, throw, break) u else grani. Ovo čini kod ravnijim i čitljivijim — bez ugnježdenih if blokova. Ako optional ne može biti nil — koristite force unwrap (!), samo kada ste potpuno sigurni. U mobilnoj aplikaciji, guard let pomaže u izbegavanju padova pri obradi opcionih vrednosti.

Optional Chaining (user?.address?.city) i nil-coalescing (??) su sintaksni šećer za rad sa optional-ima bez raspakivanja. U IT Sectr-u, koristimo guard let za validaciju ulaznih parametara API-ja i zahtevamo od tima da izbegava force unwrap bez eksplicitnog komentara. Rukovalac greškama na svakom nivou štiti od neočekivanih otkaza.

Obrada grešaka u Android-u: Try-Catch, Elvis, Sealed Class

Kotlin je primarni jezik za Android razvoj. Nasleđuje try-catch iz Jave, ali dodaje sigurnije alternative: elvis operator, require, check i sealed class. Obrada grešaka u Kotlin-u se zasniva na kombinaciji ovih mehanizama. Za razliku od Swift-a, Kotlin ne zahteva obradu proverenih izuzetaka (svi izuzeci su neprovereni). Za obradu grešaka u mobilnim aplikacijama na Android-u, koristite sealed class kao primarni obrazac.

Try-Catch i Elvis operator

Try-catch u Kotlin-u radi kao izraz — vraća vrednost. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Ovo skraćuje kod. Elvis operator (?:) je analog nil-coalescing za nullable tipove: val name = user?.name ?: "Guest". Za obradu grešaka u mobilnim aplikacijama, try-catch kao izraz je najsažetiji pristup.

Sealed class je moćan alat za modeliranje stanja uspeha i greške. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Kada se koristi u when izrazu, kompajler proverava potpunost grana. Obrada grešaka putem sealed class garantuje da nijedno stanje ne ostane neobrađeno.

// Sealed class + try-catch — tipičan obrazac za 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}")
    }
}

U primeru, sealed class NetworkResult modelira dva stanja: uspeh sa podacima i grešku sa porukom. Funkcija fetchUser vraća rezultat u svakom slučaju, a pozivajući kod obrađuje obe grane putem when. Ovo eliminiše mogućnost neobrađene greške. Obrada grešaka putem sealed class je standard za Android razvoj u IT Sectr-u.

Obrada grešaka u Kotlin-u: Result i Either

Result je ugrađeni Kotlin tip za predstavljanje rezultata operacije koja može otkazati. Primorava na obradu uspeha i neuspeha putem fold, getOrThrow ili map. Result je koristan u asinhronim lancima (coroutines). Obrada grešaka pomoću Result je standard za mobilni razvoj u Kotlin-u.

Result vs Either

Either je funkcionalni tip iz Arrow biblioteke koji omogućava vraćanje vrednosti jednog od dva tipa (Left — greška, Right — uspeh). Za razliku od Result, Either može sadržati bilo koji korisnički definisan tip greške. Za jednostavne projekte, ugrađeni Result je dovoljan; za složene projekte, koristite Either iz Arrow-a. Izbor alata za obradu grešaka zavisi od složenosti projekta.

Propagacija grešaka

Propagacija grešaka je mehanizam gde se greška propagira naviše na steku poziva dok se ne obradi. U Kotlin-u, ovo se dešava podrazumevano (neprovereni izuzeci). U Swift-u, ovo se odnosi samo na funkcije označene sa throws. Kod Result i Either, greške se ne propagiraju — ostaju u tipu i morate ih obraditi. Ovo čini obradu grešaka u mobilnim aplikacijama sigurnijom.

Tabela prikazuje ključne razlike. iOS zahteva eksplicitnu deklaraciju grešaka (throws), što čini kod sigurnijim, ali opširnijim. Android se oslanja na disciplinu programera. U IT Sectr-u, koristimo sealed class za Android i throws za iOS — to je najbolja praksa obe platforme za obradu grešaka u mobilnim aplikacijama.

Crash Reporting: Crashlytics i Sentry

Crash reporting je sistem za prikupljanje i analizu padova aplikacije. Crash reporting je neizostavni deo obrade grešaka u produkciji. Bez njega, saznajete za probleme od korisnika, što je neprihvatljivo za produkciju. Dva glavna alata: Firebase Crashlytics (besplatno) i Sentry (besplatno za osnovnu upotrebu). Za obradu grešaka u mobilnim aplikacijama, uvek implementirajte crash reporting od prvog izdanja.

Firebase Crashlytics

Crashlytics je deo Firebase-a. Automatski prikuplja padove, grupiše ih prema steku poziva i prikazuje broj pogođenih korisnika. Podržava evidentiranje nefatalnih grešaka putem recordException(). Integracija: dodajte SDK u build.gradle (Android) ili Podfile (iOS). Crashlytics je najbolji besplatni alat za obradu grešaka na početku projekta.

Sentry

Sentry je višeplatformski sistem za praćenje grešaka. Za razliku od Crashlytics-a, Sentry pruža detaljno praćenje (breadcrumbs), praćenje performansi i podršku za React Native. Omogućava pregled stanja aplikacije u trenutku greške. IT Sectr preporučuje Sentry za projekte kojima je potrebna potpuna kontrola nad obradom grešaka u mobilnom razvoju.

Error Boundary u React Native-u

Error Boundary je React komponenta koja hvata JavaScript greške u stablu podređenih komponenti i prikazuje rezervni korisnički interfejs, sprečavajući potpuni pad aplikacije. Error Boundary je ključna komponenta za obradu grešaka u React Native-u. Koristite error boundaries za kritične ekrane i navigaciju. Obrada grešaka u mobilnim aplikacijama na React Native-u zahteva pravilno podešavanje Error Boundary na najvišem nivou.

Implementacija Error Boundary

Error Boundary se kreira putem componentDidCatch(error, errorInfo) ili static getDerivedStateFromError(error). Ne hvata greške u asinhronom kodu (setTimeout, requestAnimationFrame), renderovanju na serveru ili izvornim greškama (Native Modules). Za evidentiranje, koristite crash reporting SDK unutar componentDidCatch. Error Boundary je jednostavan, ali efikasan rukovalac greškama za sloj korisničkog interfejsa.

Fatalne i nefatalne greške

Fatalna greška je neobrađeni izuzetak koji dovodi do pada aplikacije. Nefatalna greška je izuzetak koji ste uhvatili i obradili, ali ukazuje na problem u kodu. Nefatalne greške se evidentiraju putem Crashlytics/Sentry i pomažu u pronalaženju grešaka pre nego što postanu fatalne. I fatalne i nefatalne greške zahtevaju pravilnu obradu grešaka u mobilnom razvoju.