Global Exception Handler: esensya, prinsipyo ng trabaho at implementasyon sa mga proyekto

Ano ang Global Exception Handler?

Global Exception Handler — ay isang sentralisadong mekanismo para sa pag-intercept ng mga exception na hindi na-handle sa antas ng mga indibidwal na function o module ng application. Sa konteksto ng mobile development, ang naturang handler ay nagsisilbing huling linya ng depensa bago ang sapilitang pagtatapos ng proseso.

Ang iOS at Android ay nagbibigay ng built-in na API para sa pag-install ng global handler. Gumagamit ang Apple ng NSSetUncaughtExceptionHandler para sa Objective-C environment, at nag-aalok ang Google ng Thread.setDefaultUncaughtExceptionHandler sa Java/Kotlin. Ang parehong mekanismo ay pumipigil sa mga exception na hindi nahuli ng try-catch constructs sa lahat ng thread ng application.

Ayon sa datos ng Crashlytics (Google, 2024), humigit-kumulang 25% ng crash ay nangyayari dahil sa hindi naprosesong exception sa background thread — isang lugar kung saan ang Global Exception Handler ay lubhang kritikal. Ang mga developer ay madalas na nakatutok sa UI thread, nakakalimutan ang mga asynchronous na operasyon.

Ang paggamit ng global handler ay hindi pumapalit sa local error handling, kundi nagpupuno dito. Ang pangunahing gawain ay i-save ang maximum na impormasyon tungkol sa estado ng application sa sandali ng exception at matapos nang tama.

Paano gumagana ang global exception handler

Mekanismo ng trabaho ng Global Exception Handler ay batay sa pag-intercept ng mga signal ng operating system o runtime exception. Kapag ang code ay nag-throw ng exception na hindi nahuli ng anumang try-catch block, ang kontrol ay ililipat sa paunang nakatakdang handler.

Sa iOS platform, ang handler ay nagrerehistro sa pamamagitan ng NSSetUncaughtExceptionHandler at tumatanggap ng NSException object na may kumpletong stack trace. Sa Android, ginagamit ang Thread.setDefaultUncaughtExceptionHandler, na tumatanggap ng Thread at Throwable — nagbibigay ito ng access sa uri ng exception, mensahe, at call stack.

Pagkatapos matanggap ang crash data, ginagawa ng handler ang tatlong mandatoryong aksyon: pagsulat ng log sa local storage, pagpapadala ng report sa Crashlytics o Sentry, at tamang pagtatapos ng application. Ayon sa Apple WWDC 2023, ang oras ng pagtatrabaho ng handler ay limitado sa 5 segundo — pagkatapos nito, sapilitang tinatapos ng system ang proseso.

Para sa Swift applications mula iOS 13, lumitaw ang Signals API na nagpoproseso hindi lamang ng mga exception kundi pati na rin ng mga signal ng operating system — SIGABRT, SIGSEGV at SIGBUS, pinalalawak ang coverage ng handler sa mga low-level memory error.

Implementasyon ng Global Exception Handler sa iOS

Implementasyon ng global handler sa iOS ay nangangailangan ng pag-set ng C function sa pamamagitan ng NSSetUncaughtExceptionHandler. Ang handler ay tinatawag nang synchronously sa sandali ng hindi naprosesong exception at natatanggap ang kumpletong konteksto ng error.

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

    // I-save ang crash log sa lokal na file
    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);
}

Mahalagang tampok ng iOS implementation: ang handler ay pumipigil lamang ng Objective-C exception. Ang Swift errors na gumagamit ng throw-catch mechanism ay hindi nahuhuli ng handler na ito — nangangailangan sila ng hiwalay na pagproseso sa pamamagitan ng Swift Error Handling. Mula iOS 14, inirerekomenda ng Apple na pagsamahin ang NSSetUncaughtExceptionHandler sa Signals API para sa maximum coverage.

Ayon sa Apple Technical Note TN2151, pagkatapos tawagan ang handler, ang application ay dapat matapos sa loob ng 5 segundo. Anumang pagtatangka na ipagpatuloy ang execution pagkatapos bumalik mula sa handler ay nagdudulot ng hindi tiyak na pag-uugali at paulit-ulit na crash.

Implementasyon ng Global Exception Handler sa Android

Android ay nagbibigay ng mas flexible na mekanismo para sa global exception handling sa pamamagitan ng Thread.setDefaultUncaughtExceptionHandler. Ang handler ay tumatanggap ng reference sa thread kung saan nangyari ang exception at ang Throwable object mismo.

class GlobalExceptionHandler : Thread.UncaughtExceptionHandler {

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

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

        // Ipadala sa Crashlytics
        FirebaseCrashlytics.getInstance()
            .recordException(throwable)

        // Tapusin ang proseso
        android.os.Process.killProcess(
            android.os.Process.myPid()
        )
    }
}

// Pag-install sa Application.onCreate
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Thread.setDefaultUncaughtExceptionHandler(
            GlobalExceptionHandler()
        )
    }
}

Pangunahing pagkakaiba ng Android implementation: bawat thread ay may sariling handler, at ang setDefaultUncaughtExceptionHandler ay nagtatakda ng handler para sa lahat ng thread na walang indibidwal na handler. Ito ay nagsisiguro ng global coverage — mula sa UI thread hanggang sa background AsyncTask at coroutine.

Sa Android 12+ lumitaw ang limitasyon: pagkatapos tawagan ang uncaughtException, ang application ay dapat matapos sa loob ng 100 millisecond. Kung ang handler ay nagsasagawa ng mahabang operasyon, maaaring patayin ng system ang proseso bago matapos ang pagsulat ng log. Inirerekomenda ang paggamit ng background service para sa pagpapadala ng crash report.

Pinakamahusay na kasanayan sa Global Exception Handler

Unang panuntunan — huwag subukang ibalik ang application pagkatapos ng hindi naprosesong exception. Ang estado ng application pagkatapos ng crash ay hindi tiyak, at ang pagpapatuloy ng trabaho ay maaaring humantong sa pagkasira ng data ng user.

Pag-minimize ng oras ng pagtatrabaho ng handler

Limitasyon sa oras — ang pangunahing teknikal na constraint ng Global Exception Handler. Sa iOS ito ay 5 segundo, sa Android — 100 millisecond. Sa loob ng handler, pinapayagan lamang ang pag-save ng minimal na set ng data: uri ng exception, call stack, at estado ng ilang pangunahing variable.

Ang pagpapadala ng network requests, pagsulat sa database, at kumplikadong serialization ay dapat ilipat sa naantalang mekanismo — halimbawa, i-save ang log sa isang file at ipadala ito sa susunod na paglunsad ng application.

Kombinasyon sa crash-reporting system

Mga serbisyo ng crash-reporting — Firebase Crashlytics, Sentry, Bugsnag — sila mismo ang nag-iinstall ng global handler. Kung ang developer ay nag-install ng sarili niyang handler sa ibabaw ng mga ito, dapat niyang ipasa ang kontrol sa crash-reporting system pagkatapos ng kanyang mga aksyon. Sa Android, ginagamit ang composition ng handler: isagawa ang sariling logic, pagkatapos ay tawagan ang nakaraang handler.

Para sa Firebase Crashlytics, inirerekomenda na huwag mag-install ng custom na Thread.setDefaultUncaughtExceptionHandler — ang Crashlytics SDK ay awtomatikong gumagawa nito sa initialization.

Pag-log ng karagdagang impormasyon

Konteksto ng user — bukod sa standard call stack, kapaki-pakinabang na i-log ang bersyon ng application, bersyon ng OS, dami ng libreng memory, at oras ng trabaho hanggang sa crash. Ang mga datos na ito ay kritikal para sa reproduction at pag-aayos ng problema.

Sa iOS, ang NSSetUncaughtExceptionHandler ay maaaring gamitin hindi lamang para sa pagsulat, kundi pati na rin para sa pansamantalang pag-iimbak ng data sa NSUserDefaults na may synchronize flag — ginagarantiyahan nito ang pag-save ng data kahit na sa agarang pagtatapos ng proseso.

Pag-test ng handler bago ang release

Mandatoryong pag-test — ang Global Exception Handler ay dapat i-test sa bawat yugto ng CI/CD. Sa iOS, ang test exception ay maaaring simulan sa pamamagitan ng @throw NSException, sa Android — sa pamamagitan ng throw RuntimeException(). Sinusuri kung ang handler ay tinawag, ang log ay na-save, at ang application ay natapos nang tama.

Ayon sa Google I/O 2023, higit sa 30% ng crash sa produksyon ay nangyayari sa mga device na hindi na-test ng developer — iba't ibang bersyon ng Android, custom firmware, limitadong memory.

Mga karaniwang pagkakamali sa paggamit ng handler

Una at pinakakaraniwang pagkakamali — pagtatangkang ipagpatuloy ang execution ng application pagkatapos ma-handle ang exception. Pagkatapos tawagan ang uncaughtException, ang application ay nasa hindi matatag na estado, at anumang karagdagang operasyon ay maaaring magdulot ng kaskada ng error at pagkasira ng data.

Pangalawang pagkakamali — pagsasagawa ng mahabang operasyon sa loob ng handler. Ang network requests, pagsulat ng malalaking file, o kumplikadong computations ay hindi natatapos bago ang sapilitang pagtatapos ng proseso. Ayon sa Apple Technical Q&A QA1468, ang pagtatangkang magpadala ng HTTP request sa loob ng handler ang pangunahing dahilan ng nawawalang crash reports.

Pangatlong pagkakamali — pagbalewala sa mga background thread. Ang Global Exception Handler na naka-set lamang para sa main thread ay hindi nagpoprotekta laban sa crash sa coroutine, DispatchQueue, AsyncTask, o RxJava. Sa Android, bawat thread ay dapat may sariling handler — at ang setDefaultUncaughtExceptionHandler ay nalulutas lamang ang problemang ito para sa mga thread na walang indibidwal na handler.

Pang-apat na pagkakamali — kawalan ng fallback para sa mga signal ng operating system. Ang NSSetUncaughtExceptionHandler sa iOS ay hindi pumipigil sa SIGABRT, SIGSEGV, at SIGBUS. Para sa mga signal na ito, kinakailangan ang hiwalay na pag-install ng handler sa pamamagitan ng sigaction API. Natutuklasan lamang ito ng mga developer kapag ang application ay nag-crash nang walang anumang crash report.

Pang-limang pagkakamali — pag-log ng kumpidensyal na data. Ang mga email, authorization token, o personal na data ng user ay napapasok sa crash log. Ito ay lumalabag sa GDPR at Apple App Store Review Guidelines. Palaging i-filter ang ipinapadalang data sa pamamagitan ng regex o whitelist ng mga pinapayagang field.