Fatal Error: bu nədir, əsas səbəbləri və qarşısını almaq üsulları

Fatal Error nədir

Fatal Error — proqramın sonrakı icrasının mümkün olmadığı səhvdir. Əməliyyat sistemi və ya virtual maşın məlumatların zədələnməsinin qarşısını almaq üçün prosesi dayandırır. iOS-da kritik səhv SIGABRT və ya SIGSEGV siqnalına, Android-də isə kök handlerə çatan və prosesi dayandıran idarə olunmayan istisnaya səbəb olur. Tətbiq dərhal bağlanır, istifadəçi əsas ekrana qayıdır.

Kritik səhvin əlamətləri

Kritik səhvin xarakterik əlamətləri: tam stack trace ilə crash hesabatı, tətbiqin gözlənilməz yox olması, sistem jurnalında prosesin dayandırılması haqqında qeyd, bağlanmadan əvvəl qara və ya ağ ekran. İstifadəçi seansı bərpa etmək imkanı olmadan əsas ekranı görür — tətbiqi sıfır vəziyyətdən yenidən başlatmaq lazımdır. iOS-da crash Xcode Organizer vasitəsilə əldə olunan .crash faylına yazılır.

Biznes metrikalara təsiri

Hər crash istifadəçi retensiyasına mənfi təsir göstərir. Google Play Console 2024 məlumatlarına görə, crash-free rate 99.5%-dən aşağı olan tətbiqlər axtarış və tövsiyələrdə aşağı reytinq alır. Crash-rate App Store və Google Play üçün əsas keyfiyyət göstəricilərindən biridir — yüksək kritik səhv səviyyəsi yeniləmələrin dərcini bloklaya bilər. Maliyyə və tibb tətbiqləri üçün crash-free rate 99.9%-dən aşağı qəbuledilməz hesab olunur.

Kritik səhvlərin səbəbləri

Null-pointer dereference — mobil tətbiqlərdə kritik səhvlərin aparıcı səbəbi. Null olan obyektin xassəsinə və ya metoduna müraciət cəhdi Android-də NullPointerException, iOS-da isə EXC_BAD_ACCESS yaradır. JetBrains 2023 məlumatlarına görə, bütün istehsalat crash-lərinin təxminən 28%-i null göstəricilərlə bağlıdır. Kotlin-də null-safety sistemi bu faizi əhəmiyyətli dərəcədə azaldır, lakin force unwrap və Java uyğumluğu problem mənbəyi olaraq qalır.

Index-out-of-bounds

Mövcud olmayan indeks üzrə kolleksiya elementinə müraciət — crash-lərin tezliyə görə ikinci səbəbi. Java və Kotlin-də bu ArrayIndexOutOfBoundsException, Swift-də isə fatal error: Index out of range şəklindədir. Əksər hallarda filtrləmə və ya kolleksiyanın dinamik ölçüsü dəyişikliyindən sonra siyahılarla işləyərkən baş verir. getOrNull (Kotlin) və ya indices.contains (Swift) kimi təhlükəsiz metodlardan istifadə bu tip kritik səhvlərin qarşısını alır.

Resursla bağlı crash-lər

Yaddaşın çatışmaması (OutOfMemoryError), yığının daşması (StackOverflowError), mövcud olmayan resursun yüklənməsi — resurs səhvləri çox vaxt kritikdir və çətin təkrarlanır. OutOfMemoryError böyük şəkillərin sıxışdırılmadan yüklənməsi və ya boşaldılmayan istinadlar səbəbindən yaddaş sızıntısı zamanı baş verir. StackOverflowError — əsas halı olmayan dərin rekursiya və ya deleqatlar zəncirində tsiklik çağırışlar zamanı yaranır.

Concurrency səhvləri

Deadlock, race condition, iterasiya zamanı kolleksiyanın dəyişdirilməsi — çoxaxın səhvləri qeyri-deterministik şəkildə özünü göstərir və diaqnoz üçün ən çətindir. Android-də müxtəlif axınlardan ArrayList-in dəyişdirilməsi zamanı ConcurrentModificationException, iOS-da sinxronizasiyasız NSMutableArray-in dəyişdirilməsi səbəbindən crash baş verir. Kotlin korutinləri (structured concurrency) və ya Swift Actors (iOS 16+) concurrency crash-lərinin ehtimalını azaldır.

Fatal Error vs Non-Fatal Error

Əsas fərq — bərpa olunma imkanı. Non-Fatal Error proqramın işə davam etməsinə imkan verir: şəbəkə timeout-u try-catch ilə idarə olunur, pars xətası standart dəyərlə əvəz olunur. Fatal Error-un belə bir yolu yoxdur — crash qaçınılmazdır və tətbiq yenidən başladılmalıdır. Bu səhv növləri arasındakı sərhəd tətbiqin arxitekturası ilə müyən edilir.

Eyni səhv bir platformada fatal, digərində isə non-fatal ola bilər. Sıfıra bölmə Java/Kotlin-də ArithmeticException atır (kritik deyil — tutula bilər), Swift-də isə fatal error: Division by zero (tutulması mümkün olmayan crash) yaradır. Tərtibatçı səhv idarəetməsini layihələndirərkən müəyyən dilin və icra mühitinin davranışını nəzərə almalıdır. Fatal və non-fatal arasındakı sərhədin başa düşülməsi etibarlı mobil tətbiq arxitekturasının qurulmasının əsasıdır.

Kritik səhvlərin diaqnostikası

Firebase Crashlytics — mobil tətbiqlərdə crash-lərin diaqnostikası üçün de-fakto standartdır. SDK avtomatik olaraq stack trace, cihaz vəziyyəti, əməliyyat sistemi versiyası və crash-dan əvvəlki jurnalları toplayır. Dashboard eyni crash-ləri bir issue-də qruplaşdırır, təsirlənmiş istifadəçilərin sayını, təkrarlanma tezliyini və crash-in baş verdiyi tətbiq versiyasını göstərir.

// Android tətbiqində Crashlytics-in işə salınması
class MainApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        Crashlytics.setCustomKey("build_type", "production")
    }
}

// Crash diaqnostikası üçün fərdi məlumatların təyin edilməsi
Crashlytics.setUserId("user_12345")
Crashlytics.setCustomKey("screen", "ProfileFragment")
Crashlytics.setCustomKey("api_response", responseCode)

// inteqrasiyanın test edilməsi üçün məcburi crash
Crashlytics.crash()

Sentry — daha ətraflı diaqnostika ilə alternativ həll. Sentry təkcə stack trace deyil, həm də bütün dəyişənlərin vəziyyətini, səhvə qədərki hadisələrin ardıcıllığını və icra kontekstini göstərir. Sentry-dəki Breadcrumbs kritik səhvdən əvvəl istifadəçinin hərəkətlər zəncirini bərpa etməyə imkan verir: dümə klikləri, ekranlar arası keçidlər, şəbəkə sorğuları. Sentry-də keyfiyyətin kompleks təhlili üçün performans və sessiyaların monitorinqi mövcuddur.

Symbolizasiya və deobfuskasiya

iOS-da crash-lərin düzgün diaqnostikası üçün Crashlytics və ya Sentry-də dSYM fayllarının (debug symbols) yüklənməsi tələb olunur. dSYM olmadan stack trace funksiya adları əvəzinə yalnız yaddaş ünvanlarını ehtiva edəcək. Android üçün ProGuard və ya R8 istifadə edərkən mapping fayllarının yüklənməsi tələb olunur. Xcode-da build phase və ya Gradle plagin vasitəsilə dSYM yüklənməsinin avtomatlaşdırılması istehsalat qurğuları üçün məcburidir.

Kritik səhvlərin qarşısının alınması

Əsas qarşısını alma metodu — bütün optional və nullable dəyərlərin safe unwrapping-i. Swift-də if-let və Kotlin-də ?: ilə let istifadəsi null-pointer səhvlərini aradan qaldırır. Dəyərin mövcudluğuna zəmanət olmadan heç bir force unwrap. Həm Kotlin, həm də Swift kompilyatorları potensial təhlükəli əməliyyatlar barədə xəbərdarlıq edir — istehsalat kodunda bu xəbərdarlıqlara məhəl qoymaq olmaz.

// Safe unwrapping vasitəsilə fatal error-un QARŞISININ ALINMASI
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
}

// Kolleksiya elementlərinə təhlükəsiz müraciət
func safeGet <T>(items: [T], index: Int) -> T? {
    guard items.indices.contains(index) else { return nil }
    return items[index]
}

// Müraciətdən əvvəl massiv sərhədlərinin yoxlanması
let numbers = [1, 2, 3]
if numbers.indices.contains(5) {
    print(numbers[5])
} else {
    print("Index out of range")
}

Defensive programming — ikinci müdafiə səviyyəsi. Həmişə funksiyaların giriş parametrlərini yoxlayın, force unwrap əvəzinə Optional və ya Result qaytarın, inkişaf mərhələsində səhvlərin erkən aşkarlanması üçün debug qurğularında assert istifadə edin. Sərhəd halları (null, boş kolleksiyalar, səhv indekslər) üçün vahid testlər tətbiqin biznes məntiqinin bütün açıq giriş nöqtələrini əhatə etməlidir.

UI təbəqəsi üçün Error Boundary

React Native və SwiftUI-də error boundary təyin etmək olar — render zamanı kritik səhvləri tutan və crash əvəzinə ehtiyat interfeys göstərən komponent. Bu, istifadəçi təcrübəsi baxımından kritik UI səhvini non-fatal-a çevirir — tətbiq işləməyə davam edir və istifadəçi ağ ekran əvəzinə interfeysin konkret blokunda səhv mesajı görür.

CI/CD-də crash yoxlamaları

CI/CD pipeline-ında avtomatik yoxlamaların inteqrasiyası: statik təhlil (Kotlin üçün Detekt, Swift üçün SwiftLint), real cihazlarda UI testlərinin işə salınması, test mühitində crash-free rate-in yoxlanması. Crash-rate həddini aşdıqda merg-in bloklanması (tövsiyə olunan hədd — commit başına 0.1%-dən çox yeni crash).