Fatal Error: ana nedenler ve önleme yöntemleri

Fatal Error Nedir

Fatal Error, programın yürütülmesinin devam edemediği bir hatadır. İşletim sistemi veya sanal makine, veri bozulmasını önlemek için işlemi sonlandırır. iOS'ta ölümcül bir hata SIGABRT veya SIGSEGV sinyali tetikler; Android'de ise kök işleyiciye ulaşan işlenmemiş bir istisna işlemi sonlandırır. Uygulama anında kapanır ve kullanıcı Ana Ekrana döner.

Ölümcül Hatanın Belirtileri

Ölümcül hatanın karakteristik belirtileri: tam yığın izi içeren bir çökme raporu, uygulamanın beklenmedik şekilde kaybolması, işlem sonlandırmayla ilgili sistem günlüğü girişi, kapanmadan önce siyah veya beyaz ekran. Kullanıcı, oturumu kurtarma imkanı olmadan Ana ekranı görür — uygulama sıfırdan yeniden başlatılmalıdır. iOS'ta çökmeye Xcode Organizer üzerinden erişilebilen bir .crash dosyası eşlik eder.

İş Metriklerine Etkisi

Her çökme kullanıcı tutma oranını olumsuz etkiler. Google Play Console 2024'e göre, crash-free oranı %99,5'in altında olan uygulamalar arama ve önerilerde daha düşük puan alır. Çökme oranı, App Store ve Google Play için temel kalite sinyallerinden biridir — yüksek düzeyde ölümcül hata, güncelleme yayınlamayı engelleyebilir. Finans ve tıp uygulamaları için %99,9'un altındaki crash-free oranı kabul edilemez olarak değerlendirilir.

Ölümcül Hataların Nedenleri

Null işaretçi başvurusu mobil uygulamalarda ölümcül hataların önde gelen nedenidir. Null olan bir nesnenin özelliğine veya yöntemine erişmeye çalışmak Android'de NullPointerException'a veya iOS'ta EXC_BAD_ACCESS'e neden olur. JetBrains 2023'e göre, tüm üretim çökmelerinin yaklaşık %28'i null işaretçilerle ilgilidir. Kotlin'in null-safety sistemi bu oranı önemli ölçüde azaltır, ancak force unwrap ve Java uyumluluğu sorunun kaynakları olmaya devam eder.

Dizin Sınır Dışı

Var olmayan bir dizinle koleksiyon öğesine erişmek çökmelerin ikinci en yaygın nedenidir. Java ve Kotlin'de bu ArrayIndexOutOfBoundsException'dır; Swift'te — fatal error: Index out of range. Bu genellikle filtreleme sonrası veya koleksiyon boyutunun dinamik olarak değiştirilmesi sırasında listelerle çalışırken ortaya çıkar. getOrNull (Kotlin) veya indices.contains (Swift) gibi güvenli yöntemler kullanmak bu tür ölümcül hatayı önler.

Kaynakla İlgili Çökmeler

Bellek yetersizliği (OutOfMemoryError), yığın taşması (StackOverflowError), var olmayan kaynak yükleme — kaynak hataları genellikle ölümcüldür ve tekrarlanması zordur. OutOfMemoryError, sıkıştırma olmadan büyük resimler yüklerken veya serbest bırakılmayan referanslar nedeniyle bellek sızıntısı nedeniyle oluşur. StackOverflowError, temel durum olmadan derin özyineleme veya temsilci zincirinde döngüsel çağrılar nedeniyle oluşur.

Eşzamanlılık Hataları

Deadlock, yarış koşulu, yineleme sırasında koleksiyon değişikliği — çoklu iş parçacığı hataları belirli olmayan bir şekilde ortaya çıkar ve teşhis edilmesi en zor olanlardır. Android'de, farklı iş parçacıklarından ArrayList değiştirilirken ConcurrentModificationException; iOS'ta, senkronizasyon olmadan NSMutableArray değiştirilirken çökme meydana gelir. Kotlin coroutines (yapılandırılmış eşzamanlılık) veya Swift Actors (iOS 16+) kullanmak eşzamanlılık çökmeleri olasılığını azaltır.

Fatal Error vs Non-Fatal Error

Temel fark kurtarılabilirliktir. Non-Fatal Error programın devam etmesine izin verir: ağ zaman aşımı try-catch ile işlenir, ayrıştırma hatası varsayılan bir değerle değiştirilir. Fatal Error'un böyle bir yolu yoktur — çökme kaçınılmazdır ve uygulama yeniden başlatılmalıdır. Bu hata türleri arasındaki sınır uygulama mimarisi tarafından belirlenir.

Aynı hata bir platformda ölümcül, diğerinde ölümcül olmayabilir. Sıfıra bölme Java/Kotlin'de ArithmeticException fırlatır (ölümcül değil — yakalanabilir), Swift'te ise fatal error: Division by zero'ya neden olur (yakalanamayan çökme). Geliştirici, hata işleme tasarlarken belirli dil ve çalışma zamanı ortamının davranışını hesaba katmalıdır. Ölümcül ve ölümcül olmayan arasındaki sınırı anlamak, mobil uygulamada hataya dayanıklı mimari kurmanın temelidir.

Ölümcül Hataların Teşhisi

Firebase Crashlytics, mobil uygulamalarda çökmeleri teşhis etmek için fiili standarttır. SDK, çökmeden hemen önce yığın izini, cihaz durumunu, işletim sistemi sürümünü ve günlükleri otomatik olarak toplar. Gösterge paneli, aynı çökmeleri tek bir sorunda gruplayarak etkilenen kullanıcı sayısını, sıklığı ve çökmenin meydana geldiği uygulama sürümünü gösterir.

// Bir Android uygulamasında Crashlytics'i başlatma
class MainApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        Crashlytics.setCustomKey("build_type", "production")
    }
}

// Çökme teşhisi için özel kullanıcı verileri ayarlama
Crashlytics.setUserId("user_12345")
Crashlytics.setCustomKey("screen", "ProfileFragment")
Crashlytics.setCustomKey("api_response", responseCode)

// Entegrasyon testi için zorla çökme
Crashlytics.crash()

Sentry daha ayrıntılı teşhis sunan bir alternatiftir. Sentry yalnızca yığın izini değil, aynı zamanda tüm değişkenlerin durumunu, hatadan önceki olay sırasını ve yürütme bağlamını da gösterir. Sentry'nin Breadcrumbs özelliği, ölümcül hatadan önceki kullanıcı eylemleri zincirini (düğme tıklamaları, ekran geçişleri, ağ istekleri) yeniden oluşturmayı sağlar. Sentry ayrıca kapsamlı kalite analizi için performans ve oturum izleme sunar.

Sembolleştirme ve Kod Gizleme Çözme

iOS'ta çökmelerin doğru teşhisi için dSYM dosyalarının (hata ayıklama sembolleri) Crashlytics veya Sentry'ye yüklenmesi gerekir. dSYM olmadan yığın izi, işlev adları yerine yalnızca bellek adreslerini içerir. Android için ProGuard veya R8 kullanılırken eşleme dosyalarının yüklenmesi gerekir. Xcode'da derleme aşaması veya Gradle eklentisi aracılığıyla dSYM yüklemenin otomatikleştirilmesi, üretim derlemeleri için zorunludur.

Ölümcül Hataların Önlenmesi

Temel önleme yöntemi, tüm isteğe bağlı ve nullable değerlerin safe unwrappingidir. Swift'te if-let ve Kotlin'de ?: ile let kullanımı null işaretçi hatalarını ortadan kaldırır. Değer garantisi olmadan force unwrap yapılmamalıdır. Hem Kotlin hem de Swift derleyicileri potansiyel olarak tehlikeli işlemler hakkında uyarır — bu uyarılar üretim kodunda göz ardı edilemez.

// safe unwrapping ile fatal error'u ÖNLEME
func processUser(id: String) -> String {
    guard let user = database.findUser(by: id) else {
        return "User not found"
    }
    guard let email = user.email else {
        return "Email not set"
    }
    return email
}

// Koleksiyon öğelerine güvenli erişim
func safeGet <T>(items: [T], index: Int) -> T? {
    guard items.indices.contains(index) else { return nil }
    return items[index]
}

// Erişimden önce dizi sınırlarını kontrol etme
let numbers = [1, 2, 3]
if numbers.indices.contains(5) {
    print(numbers[5])
} else {
    print("Index out of range")
}

Defensive programming ikinci koruma seviyesidir. İşlevlerin girdi parametrelerini her zaman kontrol edin, force unwrap yerine Optional veya Result döndürün ve geliştirme sırasında erken hata tespiti için hata ayıklama derlemelerinde assert kullanın. Sınır durumları (null, boş koleksiyonlar, geçersiz dizinler) için birim testleri, uygulamanın iş mantığındaki tüm herkese açık giriş noktalarını kapsamalıdır.

UI Katmanı için Error Boundary

React Native ve SwiftUI'de, işleme hatalarını yakalayan ve çökme yerine yedek UI gösteren bir error boundary ayarlayabilirsiniz. Bu, kullanıcı açısından ölümcül bir UI hatasını ölümcül olmayana dönüştürür — uygulama çalışmaya devam eder ve kullanıcı beyaz ekran yerine belirli bir arayüz bloğunda hata mesajı görür.

CI/CD'de Çökme Kontrolleri

CI/CD hattına otomatik kontrollerin entegrasyonu: statik analiz (Kotlin için Detekt, Swift için SwiftLint), gerçek cihazlarda UI testleri çalıştırma, test ortamında crash-free oranını kontrol etme. Çökme oranı eşiği aşıldığında birleştirmeyi engelleme (önerilen eşik: her commit'te %0,1'den fazla yeni çökme).