Mobil geliştirmede hata yönetimi: nedir, hangi teknikler ve nasıl organize edilir

iOS'ta Hata Yönetimi: Do-Catch, Throw, Guard Let

Hata yönetimi Swift'te dört temel mekanizma üzerine kurulmuştur: do-catch, throws, guard let ve if-let. Birçok dilin aksine, Swift yakalanmamış istisnalara izin vermez — her hata açıkça işlenmeli veya throws ile bildirilmelidir. Hata yönetimi, mobil geliştirme için kritik bir beceridir ve uygulama kararlılığını doğrudan etkiler.

Do-Catch ve Throw

do-catch, throws ile işaretlenmiş işlevleri çağırmak için standart bloktur. do içinde, try ile bir işlev çağrılır ve bir hata fırlatırsa kontrol catch'e geçer. Farklı hata türleri, pattern matching ile işlenebilir. Bir hata işlenmezse, yığında yukarı doğru yayılır (Error Propagation). iOS'ta etkili hata yönetimi için do-catch'i birincil mekanizma olarak kullanın.

Throw, işlev imzasında bildirilir: func fetchData() throws -> Data. Bu, çağıran kodun try, try? veya try! ile hatayı işlemesi gerektiği anlamına gelir. try? hatayı nil'e dönüştürür, try! hata durumunda çökmeye neden olur (yalnızca başarıdan eminseniz kullanın). throw ile hata yönetimi Swift'te zorunlu bir uygulamadır.

Optional/Nullable ve Guard Let

Guard let, değer nil ise bir işlevden erken çıkmak için bir yapıdır. if-let'in aksine, guard let else dalında bir çıkış (return, throw, break) gerektirir. Bu, kodu daha düz ve okunabilir hale getirir — iç içe if blokları olmadan. Bir optional nil olamıyorsa — force unwrap (!) kullanın, yalnızca kesinlikle emin olduğunuzda. Mobil uygulamada, guard let isteğe bağlı değerleri işlerken çökmeleri önlemeye yardımcı olur.

Optional Chaining (user?.address?.city) ve nil-coalescing (??), kutuyu açmadan optional ile çalışmak için sözdizimsel şekerdir. IT Sectr'de, API giriş parametrelerini doğrulamak için guard let kullanırız ve ekibin açık bir yorum olmadan force unwrap'tan kaçınmasını zorunlu kılarız. Her seviyedeki bir hata işleyici, beklenmeyen arızalara karşı korur.

Android'de Hata Yönetimi: Try-Catch, Elvis, Sealed Class

Kotlin, Android geliştirme için birincil dildir. Java'dan try-catch'i devralır ancak daha güvenli alternatifler ekler: elvis operatörü, require, check ve sealed class. Kotlin'de hata yönetimi, bu mekanizmaların bir kombinasyonu üzerine kurulmuştur. Swift'in aksine, Kotlin kontrollü istisnaları işlemeyi gerektirmez (tüm istisnalar kontrolsüzdür). Android'de mobil uygulamalarda hata yönetimi için sealed class'ı birincil desen olarak kullanın.

Try-Catch ve Elvis Operatörü

Try-catch Kotlin'de bir ifade olarak çalışır — bir değer döndürür. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Bu, kodu kısaltır. Elvis operatörü (?:), nullable türler için nil-coalescing'in bir benzeridir: val name = user?.name ?: "Guest". Mobil uygulamalarda hata yönetimi için ifade olarak try-catch en kısa yaklaşımdır.

Sealed class, başarı ve hata durumlarını modellemek için güçlü bir araçtır. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. when ifadesinde kullanıldığında, derleyici dalların bütünlüğünü kontrol eder. sealed class ile hata yönetimi, hiçbir durumun işlenmemiş kalmamasını garanti eder.

// Sealed class + try-catch — Android için tipik desen
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}")
    }
}

Örnekte, sealed class NetworkResult iki durumu modeller: veriyle başarı ve mesajla hata. fetchUser işlevi her durumda bir sonuç döndürür ve çağıran kod when aracılığıyla her iki dalı işler. Bu, işlenmemiş hata olasılığını ortadan kaldırır. sealed class ile hata yönetimi, IT Sectr'de Android geliştirme standardıdır.

Kotlin'de Hata Yönetimi: Result ve Either

Result, başarısız olabilecek bir işlemin sonucunu temsil etmek için yerleşik bir Kotlin türüdür. fold, getOrThrow veya map aracılığıyla başarı ve başarısızlığın işlenmesini zorunlu kılar. Result, asenkron zincirlerde (coroutines) kullanışlıdır. Result ile hata yönetimi, Kotlin'de mobil geliştirme için bir standarttır.

Result vs Either

Either, Arrow kütüphanesinden iki türden birinin değerini döndürmeye izin veren işlevsel bir türdür (Left — hata, Right — başarı). Result'ın aksine, Either herhangi bir kullanıcı tanımlı hata türünü içerebilir. Basit projeler için yerleşik Result yeterlidir; karmaşık projeler için Arrow'dan Either'ı kullanın. Hata yönetimi aracının seçimi, proje karmaşıklığına bağlıdır.

Hata Yayılımı

Hata yayılımı, bir hatanın işlenene kadar çağrı yığınında yukarı doğru yayıldığı bir mekanizmadır. Kotlin'de bu varsayılan olarak gerçekleşir (kontrolsüz istisnalar). Swift'te bu yalnızca throws ile işaretlenmiş işlevler için geçerlidir. Result ve Either ile hatalar yayılmaz — tür içinde kalır ve onları işlemek zorundasınız. Bu, mobil uygulamalarda hata yönetimini daha güvenli hale getirir.

Tablo temel farklılıkları göstermektedir. iOS açık hata bildirimi (throws) gerektirir, bu da kodu daha güvenli ancak daha ayrıntılı hale getirir. Android, geliştirici disiplinine dayanır. IT Sectr'de Android için sealed class ve iOS için throws kullanıyoruz — bu, mobil uygulamalarda hata yönetimi için her iki platformun en iyi uygulamasıdır.

Crash Raporlama: Crashlytics ve Sentry

Crash raporlama, uygulama çökmelerini toplama ve analiz etme sistemidir. Crash raporlama, üretimde hata yönetiminin önemli bir parçasıdır. Onsuz, sorunları kullanıcılardan öğrenirsiniz ki bu üretim için kabul edilemez. İki ana araç: Firebase Crashlytics (ücretsiz) ve Sentry (temel kullanım için ücretsiz). Mobil uygulamalarda hata yönetimi için ilk sürümden itibaren crash raporlamayı uygulayın.

Firebase Crashlytics

Crashlytics, Firebase'in bir parçasıdır. Çökmeleri otomatik olarak toplar, çağrı yığınına göre gruplandırır ve etkilenen kullanıcı sayısını gösterir. recordException() aracılığıyla ölümcül olmayan hata günlüğünü destekler. Entegrasyon: SDK'yı build.gradle (Android) veya Podfile'a (iOS) ekleyin. Crashlytics, bir projeye başlarken hata yönetimi için en iyi ücretsiz araçtır.

Sentry

Sentry, çapraz platform bir hata izleme sistemidir. Crashlytics'in aksine Sentry, ayrıntılı izleme (breadcrumbs), performans izleme ve React Native desteği sağlar. Hata anında uygulama durumunu görüntülemenize olanak tanır. IT Sectr, mobil geliştirmede hata yönetimi üzerinde tam kontrol gerektiren projeler için Sentry'yi önerir.

React Native'de Error Boundary

Error Boundary, alt bileşen ağacındaki JavaScript hatalarını yakalayan ve yedek bir kullanıcı arayüzü göstererek uygulamanın tamamen çökmesini önleyen bir React bileşenidir. Error Boundary, React Native'de hata yönetimi için anahtar bir bileşendir. Kritik ekranlar ve gezinme için error boundaries kullanın. React Native'de mobil uygulamalarda hata yönetimi, üst düzeyde uygun Error Boundary kurulumu gerektirir.

Error Boundary Uygulaması

Error Boundary, componentDidCatch(error, errorInfo) veya static getDerivedStateFromError(error) aracılığıyla oluşturulur. Zaman uyumsuz koddaki (setTimeout, requestAnimationFrame), sunucu tarafı işlemedeki veya yerel hatalardaki (Native Modules) hataları yakalamaz. Günlüğe kaydetme için componentDidCatch içinde crash raporlama SDK'sını kullanın. Error Boundary, UI katmanı için basit ancak etkili bir hata işleyicidir.

Ölümcül ve Ölümcül Olmayan Hatalar

Ölümcül hata, uygulama çökmesine neden olan işlenmemiş bir istisnadır. Ölümcül olmayan hata, yakaladığınız ve işlediğiniz ancak kodda bir soruna işaret eden bir istisnadır. Ölümcül olmayan hatalar Crashlytics/Sentry aracılığıyla günlüğe kaydedilir ve ölümcül hale gelmeden önce hataları bulmaya yardımcı olur. Hem ölümcül hem de ölümcül olmayan hatalar, mobil geliştirmede uygun hata yönetimi gerektirir.