Global Exception Handler: esensi, prinsip kerja dan implementasi dalam proyek

Apa itu Global Exception Handler?

Global Exception Handler — adalah mekanisme terpusat untuk menangkap pengecualian yang tidak ditangani di tingkat fungsi atau modul individu aplikasi. Dalam konteks pengembangan mobile, handler semacam ini bertindak sebagai garis pertahanan terakhir sebelum proses dihentikan secara paksa.

iOS dan Android menyediakan API bawaan untuk memasang handler global. Apple menggunakan NSSetUncaughtExceptionHandler untuk lingkungan Objective-C, dan Google menawarkan Thread.setDefaultUncaughtExceptionHandler di Java/Kotlin. Kedua mekanisme menangkap pengecualian yang tidak tertangkap oleh konstruksi try-catch di semua thread aplikasi.

Menurut data Crashlytics (Google, 2024), sekitar 25% crash terjadi karena pengecualian yang tidak tertangani di thread latar belakang — area di mana Global Exception Handler sangat penting. Pengembang sering fokus pada thread UI, melupakan operasi asinkron.

Penggunaan handler global tidak menggantikan penanganan error lokal, tetapi melengkapinya. Tugas utamanya adalah menyimpan informasi maksimal tentang status aplikasi pada saat pengecualian dan mengakhiri proses dengan benar.

Bagaimana cara kerja handler pengecualian global

Mekanisme kerja Global Exception Handler didasarkan pada penangkapan sinyal sistem operasi atau pengecualian waktu proses. Ketika kode melempar pengecualian yang tidak tertangkap oleh blok try-catch mana pun, kontrol dialihkan ke handler yang telah ditentukan sebelumnya.

Di platform iOS, handler didaftarkan melalui NSSetUncaughtExceptionHandler dan menerima objek NSException dengan stack trace lengkap. Di Android, digunakan Thread.setDefaultUncaughtExceptionHandler yang menerima Thread dan Throwable — memberikan akses ke jenis pengecualian, pesan, dan tumpukan panggilan.

Setelah menerima data crash, handler melakukan tiga tindakan wajib: menulis log ke penyimpanan lokal, mengirim laporan ke Crashlytics atau Sentry, dan mengakhiri aplikasi dengan benar. Menurut Apple WWDC 2023, waktu kerja handler dibatasi 5 detik — setelah itu sistem memaksa penghentian proses.

Untuk aplikasi Swift mulai iOS 13, hadir Signals API yang memproses tidak hanya pengecualian tetapi juga sinyal sistem operasi — SIGABRT, SIGSEGV dan SIGBUS, memperluas cakupan handler ke error memori tingkat rendah.

Implementasi Global Exception Handler di iOS

Implementasi handler global di iOS memerlukan pengaturan fungsi C melalui NSSetUncaughtExceptionHandler. Handler dipanggil secara sinkron pada saat pengecualian tidak tertangani dan menerima konteks error lengkap.

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

    // Menyimpan log crash ke file lokal
    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);
}

Fitur penting implementasi iOS: handler hanya menangkap pengecualian Objective-C. Error Swift yang menggunakan mekanisme throw-catch tidak masuk ke handler ini — memerlukan penanganan terpisah melalui Swift Error Handling. Mulai iOS 14, Apple merekomendasikan menggabungkan NSSetUncaughtExceptionHandler dengan Signals API untuk cakupan maksimal.

Menurut Apple Technical Note TN2151, setelah handler dipanggil, aplikasi harus berakhir dalam 5 detik. Setiap upaya untuk melanjutkan eksekusi setelah kembali dari handler menyebabkan perilaku tidak terdefinisi dan crash berulang.

Implementasi Global Exception Handler di Android

Android menyediakan mekanisme penanganan pengecualian global yang lebih fleksibel melalui Thread.setDefaultUncaughtExceptionHandler. Handler menerima referensi ke thread tempat pengecualian terjadi dan objek Throwable itu sendiri.

class GlobalExceptionHandler : Thread.UncaughtExceptionHandler {

    override fun uncaughtException(thread: Thread, throwable: Throwable) {
        // Menyimpan log crash ke file
        val stackTrace = throwable.stackTraceToString()
        val crashLog = "CRASH: ${thread.name}\n${stackTrace}"

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

        // Mengirim ke Crashlytics
        FirebaseCrashlytics.getInstance()
            .recordException(throwable)

        // Mengakhiri proses
        android.os.Process.killProcess(
            android.os.Process.myPid()
        )
    }
}

// Pemasangan di Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Thread.setDefaultUncaughtExceptionHandler(
            GlobalExceptionHandler()
        )
    }
}

Perbedaan utama implementasi Android: setiap thread memiliki handler sendiri, dan setDefaultUncaughtExceptionHandler mengatur handler untuk semua thread yang tidak memiliki handler individual. Ini memastikan cakupan global — dari thread UI hingga AsyncTask latar belakang dan coroutine.

Di Android 12+ muncul batasan: setelah pemanggilan uncaughtException, aplikasi harus berakhir dalam 100 milidetik. Jika handler melakukan operasi yang lama, sistem dapat mematikan proses sebelum penulisan log selesai. Disarankan menggunakan layanan latar belakang untuk mengirim laporan crash.

Praktik terbaik dalam menggunakan Global Exception Handler

Aturan pertama — jangan mencoba memulihkan aplikasi setelah pengecualian tidak tertangani. Status aplikasi setelah crash tidak terdefinisi, dan melanjutkan pekerjaan dapat menyebabkan kerusakan data pengguna.

Meminimalkan waktu kerja handler

Batasan waktu — kendala teknis utama Global Exception Handler. Di iOS ini 5 detik, di Android — 100 milidetik. Di dalam handler, hanya penyimpanan data minimal yang diizinkan: jenis pengecualian, tumpukan panggilan, dan status beberapa variabel kunci.

Pengiriman permintaan jaringan, penulisan ke database, dan serialisasi kompleks harus dipindahkan ke mekanisme yang ditunda — misalnya, menyimpan log ke file dan mengirimkannya pada saat aplikasi dijalankan berikutnya.

Kombinasi dengan sistem crash-reporting

Layanan crash-reporting — Firebase Crashlytics, Sentry, Bugsnag — memasang handler global sendiri. Jika pengembang memasang handler sendiri di atasnya, ia harus menyerahkan kontrol ke sistem crash-reporting setelah tindakannya. Di Android, digunakan komposisi handler: jalankan logika sendiri, lalu panggil handler sebelumnya.

Untuk Firebase Crashlytics disarankan untuk tidak memasang Thread.setDefaultUncaughtExceptionHandler kustom sama sekali — Crashlytics SDK melakukannya secara otomatis saat inisialisasi.

Logging informasi tambahan

Konteks pengguna — selain tumpukan panggilan standar, ada baiknya mencatat versi aplikasi, versi OS, jumlah memori bebas, dan waktu kerja hingga crash. Data ini sangat penting untuk reproduksi dan perbaikan masalah.

Di iOS, NSSetUncaughtExceptionHandler dapat digunakan tidak hanya untuk menulis, tetapi juga untuk penyimpanan sementara data di NSUserDefaults dengan flag synchronize — ini menjamin penyimpanan data bahkan saat proses berakhir seketika.

Menguji handler sebelum rilis

Pengujian wajib — Global Exception Handler harus diuji di setiap tahap CI/CD. Di iOS, pengecualian uji dapat dimulai melalui @throw NSException, di Android — melalui throw RuntimeException(). Diperiksa bahwa handler dipanggil, log tersimpan, dan aplikasi berakhir dengan benar.

Menurut Google I/O 2023, lebih dari 30% crash di produksi terjadi pada perangkat yang belum diuji oleh pengembang — versi Android berbeda, firmware kustom, memori terbatas.

Kesalahan umum dalam menggunakan handler

Kesalahan pertama dan paling umum — mencoba melanjutkan eksekusi aplikasi setelah menangani pengecualian. Setelah pemanggilan uncaughtException, aplikasi berada dalam状态 tidak stabil, dan operasi lebih lanjut dapat menyebabkan kaskade error dan kerusakan data.

Kesalahan kedua — melakukan operasi yang lama di dalam handler. Permintaan jaringan, penulisan file besar, atau komputasi kompleks tidak sempat selesai sebelum penghentian paksa proses. Menurut Apple Technical Q&A QA1468, upaya mengirim permintaan HTTP di dalam handler adalah penyebab utama laporan crash yang hilang.

Kesalahan ketiga — mengabaikan thread latar belakang. Global Exception Handler yang hanya dipasang untuk thread utama tidak melindungi dari crash di coroutine, DispatchQueue, AsyncTask, atau RxJava. Di Android, setiap thread harus memiliki handler sendiri — dan setDefaultUncaughtExceptionHandler hanya menyelesaikan masalah ini untuk thread tanpa handler individual.

Kesalahan keempat — tidak adanya fallback untuk sinyal sistem operasi. NSSetUncaughtExceptionHandler di iOS tidak menangkap SIGABRT, SIGSEGV, dan SIGBUS. Untuk sinyal-sinyal ini, diperlukan pemasangan handler terpisah melalui sigaction API. Pengembang baru menyadarinya ketika aplikasi crash tanpa laporan crash sama sekali.

Kesalahan kelima — logging data rahasia. Email, token otorisasi, atau data pribadi pengguna masuk ke dalam log crash. Ini melanggar GDPR dan Apple App Store Review Guidelines. Selalu filter data yang dikirim melalui regex atau daftar putih bidang yang diizinkan.