Fatal Error: co to je, hlavní příčiny a způsoby prevence

Apa itu Fatal Error

Fatal Error — adalah error di mana kelanjutan eksekusi program tidak mungkin dilakukan. Sistem operasi atau mesin virtual menghentikan proses untuk mencegah kerusakan data. Di iOS error fatal menyebabkan sinyal SIGABRT atau SIGSEGV, di Android — exception yang tidak tertangani yang mencapai handler root dan menghentikan proses. Aplikasi langsung tertutup, pengguna kembali ke layar utama.

Tanda-tanda error fatal

Tanda khas error fatal: crash report dengan stack trace lengkap, hilangnya aplikasi secara tak terduga, catatan penghentian proses di log sistem, layar hitam atau putih sebelum penutupan. Pengguna melihat layar utama tanpa kemungkinan memulihkan sesi — aplikasi harus dimulai ulang dari keadaan nol. Di iOS crash disertai dengan penulisan ke file .crash yang dapat diakses melalui Xcode Organizer.

Dampak pada metrik bisnis

Setiap crash berdampak negatif pada retensi pengguna. Menurut Google Play Console 2024, aplikasi dengan crash-free rate di bawah 99.5% mendapat peringkat lebih rendah di pencarian dan rekomendasi. Crash-rate adalah salah satu sinyal kualitas utama untuk App Store dan Google Play — tingkat error fatal yang tinggi dapat memblokir publikasi pembaruan. Untuk aplikasi keuangan dan medis, crash-free rate di bawah 99.9% dianggap tidak dapat diterima.

Penyebab error fatal

Null-pointer dereference — penyebab utama error fatal di aplikasi mobile. Upaya mengakses properti atau method objek yang bernilai null menyebabkan NullPointerException di Android atau EXC_BAD_ACCESS di iOS. Menurut JetBrains 2023, sekitar 28% dari semua crash produksi terkait dengan null-pointer. Di Kotlin, sistem null-safety secara signifikan mengurangi persentase ini, tetapi force unwrap dan kompatibilitas Java tetap menjadi sumber masalah.

Index-out-of-bounds

Mengakses elemen koleksi dengan indeks yang tidak ada — penyebab crash kedua paling umum. Di Java dan Kotlin ini adalah ArrayIndexOutOfBoundsException, di Swift — fatal error: Index out of range. Paling sering terjadi saat bekerja dengan daftar setelah penyaringan atau perubahan ukuran dinamis koleksi. Menggunakan metode aman getOrNull (Kotlin) atau indices.contains (Swift) mencegah jenis error fatal ini.

Crash terkait resource

Kekurangan memori (OutOfMemoryError), stack overflow (StackOverflowError), memuat resource yang tidak ada — error resource seringkali fatal dan sulit direproduksi. OutOfMemoryError terjadi saat memuat gambar besar tanpa kompresi atau kebocoran memori karena referensi yang tidak dilepaskan. StackOverflowError — saat rekursi dalam tanpa kasus dasar atau panggilan siklik dalam rantai delegasi.

Concurrency error

Deadlock, race condition, modifikasi koleksi selama iterasi — error multithreading muncul secara non-deterministik dan paling sulit didiagnosis. Di Android ConcurrentModificationException saat memodifikasi ArrayList dari thread berbeda, di iOS crash karena modifikasi NSMutableArray tanpa sinkronisasi. Menggunakan coroutine Kotlin (structured concurrency) atau Swift Actors (iOS 16+) mengurangi kemungkinan crash concurrency.

Fatal Error vs Non-Fatal Error

Perbedaan utama — kemampuan pemulihan. Non-Fatal Error memungkinkan program melanjutkan pekerjaan: timeout jaringan ditangani dengan try-catch, error parsing diganti dengan nilai default. Fatal Error tidak memiliki jalur seperti itu — crash tidak terhindarkan dan aplikasi harus dimulai ulang. Batas antara jenis error ini ditentukan oleh arsitektur aplikasi.

Error yang sama bisa fatal di satu platform dan non-fatal di platform lain. Pembagian dengan nol di Java/Kotlin melempar ArithmeticException (tidak fatal — bisa ditangkap), di Swift menyebabkan fatal error: Division by zero (crash tanpa kemungkinan tangkapan). Pengembang harus mempertimbangkan perilaku bahasa spesifik dan lingkungan runtime saat merancang penanganan error. Memahami batas antara fatal dan non-fatal — dasar membangun arsitektur toleran error aplikasi mobile.

Diagnosis error fatal

Firebase Crashlytics — standar de facto untuk diagnosis crash di aplikasi mobile. SDK secara otomatis mengumpulkan stack trace, status perangkat, versi sistem operasi dan log tepat sebelum crash. Dashboard mengelompokkan crash identik dalam satu issue, menunjukkan jumlah pengguna terkena, frekuensi pengulangan dan versi aplikasi tempat crash terjadi.

// Inicializace Crashlytics v Android aplikaci
class MainApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        Crashlytics.setCustomKey("build_type", "production")
    }
}

// Nastavení uživatelských dat pro diagnostiku crashů
Crashlytics.setUserId("user_12345")
Crashlytics.setCustomKey("screen", "ProfileFragment")
Crashlytics.setCustomKey("api_response", responseCode)

// Vynucený crash pro testování integrace
Crashlytics.crash()

Sentry — alternatif dengan diagnosis lebih detail. Sentry tidak hanya menampilkan stack trace, tetapi juga status semua variabel, urutan kejadian hingga error dan konteks eksekusi. Breadcrumbs Sentry memungkinkan rekonstruksi rantai tindakan pengguna sebelum error fatal: tekan tombol, transisi antar layar, permintaan jaringan. Di Sentry tersedia pemantauan kinerja dan sesi untuk analisis kualitas komprehensif.

Symbolication dan deobfuscation

Untuk diagnosis crash yang benar di iOS diperlukan pemuatan file dSYM (debug symbols) ke Crashlytics atau Sentry. Tanpa dSYM, stack trace hanya akan berisi alamat memori, bukan nama fungsi. Untuk Android diperlukan pemuatan file mapping saat menggunakan ProGuard atau R8. Otomatisasi pemuatan dSYM melalui build phase di Xcode atau plugin Gradle wajib untuk build produksi.

Pencegahan error fatal

Metode pencegahan dasar — safe unwrapping dari semua nilai opsional dan nullable. Penggunaan if-let di Swift dan let dengan ?: di Kotlin menghilangkan error null-pointer. Tidak ada force unwrap tanpa jaminan keberadaan nilai. Kompiler Kotlin dan Swift sama-sama memperingatkan tentang operasi yang berpotensi berbahaya — peringatan ini tidak boleh diabaikan dalam kode produksi.

// PREVENCE fatal error pomocí safe unwrapping
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
}

// Bezpečný přístup k prvkům kolekce
func safeGet <T>(items: [T], index: Int) -> T? {
    guard items.indices.contains(index) else { return nil }
    return items[index]
}

// Kontrola hranic pole před přístupem
let numbers = [1, 2, 3]
if numbers.indices.contains(5) {
    print(numbers[5])
} else {
    print("Index out of range")
}

Defensive programming — tingkat perlindungan kedua. Selalu periksa parameter input fungsi, kembalikan Optional atau Result sebagai ganti force unwrap, gunakan assert di build debug untuk deteksi dini error di tahap pengembangan. Unit test untuk kasus batas (null, koleksi kosong, indeks salah) harus mencakup semua titik masuk publik logika bisnis aplikasi.

Error Boundary untuk lapisan UI

Di React Native dan SwiftUI dapat diatur error boundary — komponen yang menangkap error fatal rendering dan menampilkan UI cadangan sebagai pengganti crash. Ini mengubah error fatal UI menjadi non-fatal dari sudut pandang pengalaman pengguna — aplikasi terus berfungsi dan pengguna melihat pesan error di blok antarmuka tertentu, bukan layar putih.

Pemeriksaan crash di CI/CD

Integrasi pemeriksaan otomatis di pipeline CI/CD: analisis statis (Detekt untuk Kotlin, SwiftLint untuk Swift), menjalankan tes UI di perangkat nyata, memeriksa crash-free rate di lingkungan pengujian. Memblokir merge saat melebihi ambang crash-rate (ambang yang direkomendasikan — lebih dari 0.1% crash baru per commit).