Global Exception Handler: özü, çalışma prensibi ve projelerde uygulanması

Global Exception Handler Nedir?

Global Exception Handler — uygulamanın ayrı işlevleri veya modülleri düzeyinde işlenmeyen istisnaları yakalamak için merkezi bir mekanizmadır. Mobil geliştirme bağlamında, böyle bir işleyici, işlemin anormal sonlanmasından önceki son savunma hattı görevi görür.

iOS ve Android, küresel bir işleyici ayarlamak için yerleşik API'ler sağlar. Apple, Objective-C ortamı için NSSetUncaughtExceptionHandler'ı kullanırken, Google Java/Kotlin'de Thread.setDefaultUncaughtExceptionHandler'ı sunar. Her iki mekanizma da uygulamanın tüm iş parçacıklarında try-catch yapıları tarafından yakalanmayan istisnaları yakalar.

Crashlytics'e (Google, 2024) göre, çökmelerin yaklaşık %25'i arka plan iş parçacıklarındaki işlenmemiş istisnalardan kaynaklanır — Global Exception Handler'ın özellikle kritik olduğu bir alan. Geliştiriciler genellikle UI iş parçacığına odaklanır ve eşzamansız işlemleri unutur.

Küresel bir işleyici kullanmak, yerel hata işlemenin yerini almaz, onu tamamlar. Ana görev, istisna anında uygulama durumu hakkında maksimum bilgiyi kaydetmek ve düzgün bir şekilde sonlandırmaktır.

Küresel istisna işleyici nasıl çalışır

Çalışma mekanizması Global Exception Handler, işletim sistemi sinyallerini veya çalışma zamanı istisnalarını yakalamaya dayanır. Kod, hiçbir try-catch bloğu tarafından yakalanmayan bir istisna fırlattığında, kontrol önceden kaydedilmiş bir işleyiciye aktarılır.

iOS'ta işleyici NSSetUncaughtExceptionHandler aracılığıyla kaydedilir ve tam yığın izi ile bir NSException nesnesi alır. Android'de, Thread ve Throwable kabul eden Thread.setDefaultUncaughtExceptionHandler kullanılır — istisna türüne, mesaja ve çağrı yığınına erişim sağlar.

Çökme verilerini aldıktan sonra işleyici üç zorunlu eylem gerçekleştirir: yerel depolamaya günlük yazma, Crashlytics veya Sentry'ye rapor gönderme ve uygulamayı düzgün bir şekilde sonlandırma. Apple WWDC 2023'e göre, işleyicinin yürütme süresi 5 saniye ile sınırlıdır — bundan sonra sistem işlemi zorla sonlandırır.

iOS 13'ten itibaren Swift uygulamaları için Signals API tanıtılmıştır; bu API yalnızca istisnaları değil, aynı zamanda işletim sistemi sinyallerini (SIGABRT, SIGSEGV, SIGBUS) de işleyerek işleyicinin kapsamını düşük seviyeli bellek hatalarına kadar genişletir.

iOS'ta Global Exception Handler uygulaması

Uygulama iOS'ta küresel bir işleyici için NSSetUncaughtExceptionHandler aracılığıyla bir C işlevi ayarlamak gerekir. İşleyici, işlenmemiş bir istisna anında eşzamanlı olarak çağrılır ve tam hata bağlamını alır.

void handleUncaughtException(NSException exception) {
    NSDictionary userInfo = [exception userInfo];
    NSArray stackTrace = [exception callStackSymbols];
    NSString reason = [exception reason];

    // Kilitlenme günlüğünü yerel dosyaya kaydet
    NSString logPath = [NSSearchPathForDirectoriesInDomains(
        NSDocumentDirectory, NSUserDomainMask, YES) firstObject];
    [exceptionLog writeToFile:logPath atomically:YES];
}

int main(int argc, char argv[]) {
    NSSetUncaughtExceptionHandler(&handleUncaughtException);
    return UIApplicationMain(argc, argv, nil, nil);
}

iOS uygulamasının önemli bir özelliği: işleyici yalnızca Objective-C istisnalarını yakalar. throw-catch mekanizmasını kullanan Swift hataları bu işleyiciye ulaşmaz — Swift Error Handling aracılığıyla ayrı işleme gerektirirler. iOS 14'ten itibaren Apple, maksimum kapsam için NSSetUncaughtExceptionHandler ile Signals API'nin birleştirilmesini önerir.

Apple Technical Note TN2151'e göre, işleyici çağrıldıktan sonra uygulama 5 saniye içinde sonlanmalıdır. İşleyiciden döndükten sonra yürütmeye devam etme girişimi, tanımsız davranışa ve tekrar çökmeye yol açar.

Android'de Global Exception Handler uygulaması

Android, Thread.setDefaultUncaughtExceptionHandler aracılığıyla daha esnek bir küresel istisna işleme mekanizması sağlar. İşleyici, istisnanın oluştuğu iş parçacığına bir referans ve Throwable nesnesinin kendisini alır.

class GlobalExceptionHandler : Thread.UncaughtExceptionHandler {

    override fun uncaughtException(thread: Thread, throwable: Throwable) {
        // Kilitlenme günlüğünü dosyaya kaydet
        val stackTrace = throwable.stackTraceToString()
        val crashLog = "CRASH: ${thread.name}\n${stackTrace}"

        val file = File(context.cacheDir, "crash_log.txt")
        file.writeText(crashLog)

        // Crashlytics'e gönder
        FirebaseCrashlytics.getInstance()
            .recordException(throwable)

        // İşlemi sonlandır
        android.os.Process.killProcess(
            android.os.Process.myPid()
        )
    }
}

// Application.onCreate'da kurulum
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Thread.setDefaultUncaughtExceptionHandler(
            GlobalExceptionHandler()
        )
    }
}

Android uygulamasının temel bir farkı: her iş parçacığının kendi işleyicisi vardır ve setDefaultUncaughtExceptionHandler, bireysel işleyici atanmamış tüm iş parçacıkları için işleyiciyi ayarlar. Bu, küresel kapsam sağlar — UI iş parçacığından arka plan AsyncTask ve eşyordamlara kadar.

Android 12+'da bir sınırlama vardır: uncaughtException çağrıldıktan sonra uygulama 100 milisaniye içinde sonlanmalıdır. İşleyici uzun süreli işlemler gerçekleştirirse, sistem günlük yazılmadan önce işlemi sonlandırabilir. Çökme raporları göndermek için bir arka plan hizmeti kullanılması önerilir.

Global Exception Handler ile en iyi uygulamalar

İlk kural — işlenmemiş bir istisnadan sonra uygulama çalışmasını geri yüklemeye çalışmayın. Çökme sonrası uygulama durumu tanımsızdır ve yürütmeye devam etmek kullanıcı verilerinin bozulmasına yol açabilir.

İşleyici yürütme süresini en aza indirme

Zaman sınırı — Global Exception Handler'ın ana teknik kısıtlaması. iOS'ta 5 saniye, Android'de — 100 milisaniyedir. İşleyici içinde yalnızca minimum bir veri kümesi kaydedilmelidir: istisna türü, çağrı yığını ve birkaç anahtar değişkenin durumu.

Ağ istekleri gönderme, veritabanına yazma ve karmaşık serileştirme, ertelenmiş bir mekanizmaya aktarılmalıdır — örneğin, günlüğü bir dosyaya kaydedin ve bir sonraki uygulama başlatılışında gönderin.

Çökme raporlama sistemleriyle birleştirme

Çökme raporlama hizmetleri — Firebase Crashlytics, Sentry, Bugsnag — kendi küresel işleyicilerini ayarlar. Bir geliştirici üzerine özel bir işleyici ayarlarsa, kendi eylemlerinden sonra kontrolü çökme raporlama sistemine vermelidir. Android'de işleyici kompozisyonu kullanılır: kendi mantığınızı çalıştırın, ardından önceki işleyiciyi çağırın.

Firebase Crashlytics için özel bir Thread.setDefaultUncaughtExceptionHandler ayarlamamanız önerilir — Crashlytics SDK bunu başlatma sırasında otomatik olarak yapar.

Ek bilgileri günlükleme

Kullanıcı bağlamı — standart çağrı yığınına ek olarak, uygulama sürümünü, işletim sistemi sürümünü, kullanılabilir bellek boyutunu ve çökmeden önceki çalışma süresini günlüklemek faydalıdır. Bu veriler, sorunun yeniden üretilmesi ve çözülmesi için kritik öneme sahiptir.

iOS'ta NSSetUncaughtExceptionHandler yalnızca yazmak için değil, aynı zamanda NSUserDefaults'ta synchronize bayrağıyla geçici veri depolama için de kullanılabilir — bu, anında işlem sonlandırmada bile kalıcılığı garanti eder.

Yayın öncesi işleyiciyi test etme

Zorunlu test — Global Exception Handler, CI/CD'nin her aşamasında test edilmelidir. iOS'ta @throw NSException aracılığıyla, Android'de throw RuntimeException() aracılığıyla test istisnası tetiklenebilir. İşleyicinin çağrıldığını, günlüğün kaydedildiğini ve uygulamanın doğru şekilde sonlandığını doğrulayın.

Google I/O 2023'e göre, üretimdeki çökmelerin %30'undan fazlası geliştiricinin test etmediği cihazlarda meydana gelir — farklı Android sürümleri, özel üretici yazılımları, sınırlı bellek.

İşleyiciyi kullanırken yaygın hatalar

İlk ve en yaygın hata — bir istisnayı işledikten sonra uygulama yürütmesine devam etmeye çalışmak. uncaughtException çağrıldıktan sonra uygulama kararsız bir durumdadır ve sonraki herhangi bir işlem basamaklı hatalara ve veri bozulmasına neden olabilir.

İkinci hata — işleyici içinde uzun süreli işlemler gerçekleştirmek. Ağ istekleri, büyük dosyalar yazma veya karmaşık hesaplamalar, işlemin zorla sonlandırılmasından önce tamamlanmaz. Apple Technical Q&A QA1468'e göre, işleyici içinde HTTP isteği göndermeye çalışmak, kaybolan çökme raporlarının başlıca nedenidir.

Üçüncü hata — arka plan iş parçacıklarını yok saymak. Yalnızca ana iş parçacığı için ayarlanan Global Exception Handler, eşyordamlar, DispatchQueue, AsyncTask veya RxJava'daki çökmelere karşı koruma sağlamaz. Android'de her iş parçacığının kendi işleyicisi olmalıdır — ve setDefaultUncaughtExceptionHandler bunu yalnızca bireysel işleyicisi olmayan iş parçacıkları için çözer.

Dördüncü hata — işletim sistemi sinyalleri için yedek plan eksikliği. iOS'ta NSSetUncaughtExceptionHandler, SIGABRT, SIGSEGV ve SIGBUS'u yakalamaz. Bu sinyaller sigaction API aracılığıyla ayrı işleyici kurulumu gerektirir. Geliştiriciler bunu ancak uygulama tek bir çökme raporu olmadan çöktüğünde öğrenir.

Beşinci hata — gizli verileri günlükleme. Çökme günlüğünde e-postalar, kimlik doğrulama belirteçleri veya kullanıcıların kişisel verileri görünebilir. Bu, GDPR'yi ve Apple App Store İnceleme Yönergeleri'ni ihlal eder. İletilen verileri her zaman regex veya izin verilen alanların beyaz listesi aracılığıyla filtreleyin.