Global Exception Handler: सार, कार्य सिद्धांत और परियोजनाओं में कार्यान्वयन

Global Exception Handler क्या है?

Global Exception Handler — एक केंद्रीकृत तंत्र है जो उन अपवादों को पकड़ता है जो ऐप के अलग-अलग फंक्शन या मॉड्यूल स्तर पर हैंडल नहीं किए गए। मोबाइल डेवलपमेंट के संदर्भ में, ऐसा हैंडलर प्रक्रिया के असामान्य समापन से पहले अंतिम सुरक्षा पंक्ति के रूप में कार्य करता है।

iOS और Android वैश्विक हैंडलर सेट करने के लिए अंतर्निहित API प्रदान करते हैं। Apple Objective-C वातावरण के लिए NSSetUncaughtExceptionHandler का उपयोग करता है, जबकि Google Java/Kotlin में Thread.setDefaultUncaughtExceptionHandler प्रदान करता है। दोनों तंत्र उन अपवादों को पकड़ते हैं जो ऐप के सभी थ्रेड्स पर try-catch निर्माणों द्वारा नहीं पकड़े गए।

Crashlytics (Google, 2024) के अनुसार, लगभग 25% क्रैश बैकग्राउंड थ्रेड्स में अनहैंडल्ड अपवादों के कारण होते हैं — एक ऐसा क्षेत्र जहाँ Global Exception Handler विशेष रूप से महत्वपूर्ण है। डेवलपर्स अक्सर UI थ्रेड पर ध्यान केंद्रित करते हैं, एसिंक्रोनस संचालन को भूल जाते हैं।

वैश्विक हैंडलर का उपयोग स्थानीय त्रुटि हैंडलिंग को प्रतिस्थापित नहीं करता बल्कि इसे पूरक करता है। मुख्य कार्य है अपवाद के क्षण में ऐप की स्थिति के बारे में अधिकतम जानकारी सहेजना और सही ढंग से समाप्त करना।

वैश्विक अपवाद हैंडलर कैसे काम करता है

कार्य तंत्र Global Exception Handler ऑपरेटिंग सिस्टम सिग्नल या रनटाइम अपवादों को इंटरसेप्ट करने पर आधारित है। जब कोड एक अपवाद फेंकता है जो किसी try-catch ब्लॉक द्वारा नहीं पकड़ा जाता, तो नियंत्रण पूर्व-पंजीकृत हैंडलर को स्थानांतरित कर दिया जाता है।

iOS पर, हैंडलर NSSetUncaughtExceptionHandler के माध्यम से पंजीकृत होता है और पूर्ण स्टैक ट्रेस के साथ एक NSException ऑब्जेक्ट प्राप्त करता है। Android पर, Thread.setDefaultUncaughtExceptionHandler का उपयोग किया जाता है, जो Thread और Throwable स्वीकार करता है — जो अपवाद प्रकार, संदेश और कॉल स्टैक तक पहुँच प्रदान करता है।

क्रैश डेटा प्राप्त करने के बाद, हैंडलर तीन अनिवार्य क्रियाएँ करता है: स्थानीय स्टोरेज में लॉग लिखना, Crashlytics या Sentry को रिपोर्ट भेजना, और ऐप को सही ढंग से समाप्त करना। Apple WWDC 2023 के अनुसार, हैंडलर का निष्पादन समय 5 सेकंड तक सीमित है — उसके बाद सिस्टम प्रक्रिया को बलपूर्वक समाप्त कर देता है।

iOS 13 से शुरू होने वाले Swift ऐप्स के लिए, Signals API पेश किया गया है, जो न केवल अपवादों बल्कि ऑपरेटिंग सिस्टम सिग्नल — SIGABRT, SIGSEGV और SIGBUS — को भी हैंडल करता है, जो हैंडलर की कवरेज को निम्न-स्तरीय मेमोरी त्रुटियों तक बढ़ाता है।

iOS पर Global Exception Handler का कार्यान्वयन

कार्यान्वयन iOS पर वैश्विक हैंडलर के लिए NSSetUncaughtExceptionHandler के माध्यम से C-फंक्शन सेट करना आवश्यक है। हैंडलर एक अनहैंडल्ड अपवाद के क्षण में समकालिक रूप से कॉल किया जाता है और पूर्ण त्रुटि संदर्भ प्राप्त करता है।

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

    // क्रैश लॉग को स्थानीय फ़ाइल में सहेजें
    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);
}

iOS कार्यान्वयन की एक महत्वपूर्ण विशेषता: हैंडलर केवल Objective-C अपवादों को पकड़ता है। throw-catch तंत्र का उपयोग करने वाली Swift त्रुटियाँ इस हैंडलर तक नहीं पहुँचती हैं — उनके लिए Swift Error Handling के माध्यम से अलग हैंडलिंग आवश्यक है। iOS 14 से शुरू करके, Apple अधिकतम कवरेज के लिए NSSetUncaughtExceptionHandler को Signals API के साथ संयोजित करने की अनुशंसा करता है।

Apple Technical Note TN2151 के अनुसार, हैंडलर को कॉल करने के बाद, ऐप को 5 सेकंड के भीतर समाप्त होना चाहिए। हैंडलर से लौटने के बाद निष्पादन जारी रखने का कोई भी प्रयास अपरिभाषित व्यवहार और पुनः क्रैश की ओर ले जाता है।

Android पर Global Exception Handler का कार्यान्वयन

Android Thread.setDefaultUncaughtExceptionHandler के माध्यम से वैश्विक अपवाद हैंडलिंग के लिए अधिक लचीला तंत्र प्रदान करता है। हैंडलर उस थ्रेड का संदर्भ प्राप्त करता है जहाँ अपवाद हुआ और स्वयं Throwable ऑब्जेक्ट प्राप्त करता है।

class GlobalExceptionHandler : Thread.UncaughtExceptionHandler {

    override fun uncaughtException(thread: Thread, throwable: Throwable) {
        // क्रैश लॉग को फ़ाइल में सहेजें
        val stackTrace = throwable.stackTraceToString()
        val crashLog = "CRASH: ${thread.name}\n${stackTrace}"

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

        // Crashlytics पर भेजें
        FirebaseCrashlytics.getInstance()
            .recordException(throwable)

        // प्रक्रिया समाप्त करें
        android.os.Process.killProcess(
            android.os.Process.myPid()
        )
    }
}

// Application.onCreate में सेटअप
class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Thread.setDefaultUncaughtExceptionHandler(
            GlobalExceptionHandler()
        )
    }
}

Android कार्यान्वयन का एक मुख्य अंतर: प्रत्येक थ्रेड का अपना हैंडलर होता है, और setDefaultUncaughtExceptionHandler उन सभी थ्रेड्स के लिए हैंडलर सेट करता है जिनके पास व्यक्तिगत हैंडलर निर्दिष्ट नहीं है। यह वैश्विक कवरेज सुनिश्चित करता है — UI थ्रेड से लेकर बैकग्राउंड AsyncTask और कोरूटीन तक।

Android 12+ पर, एक सीमा है: uncaughtException को कॉल करने के बाद, ऐप को 100 मिलीसेकंड के भीतर समाप्त होना चाहिए। यदि हैंडलर लंबे समय तक चलने वाले संचालन करता है, तो सिस्टम लॉग लिखे जाने से पहले प्रक्रिया को मार सकता है। क्रैश रिपोर्ट भेजने के लिए बैकग्राउंड सेवा का उपयोग करने की अनुशंसा की जाती है।

Global Exception Handler के साथ सर्वोत्तम अभ्यास

पहला नियम — अनहैंडल्ड अपवाद के बाद ऐप संचालन को पुनर्स्थापित करने का प्रयास न करें। क्रैश के बाद ऐप की स्थिति अपरिभाषित होती है, और निष्पादन जारी रखने से उपयोगकर्ता डेटा दूषित हो सकता है।

हैंडलर निष्पादन समय को न्यूनतम करना

समय सीमा — Global Exception Handler की मुख्य तकनीकी बाधा। iOS पर यह 5 सेकंड है, Android पर — 100 मिलीसेकंड। हैंडलर के अंदर, केवल न्यूनतम डेटा सेट सहेजा जाना चाहिए: अपवाद प्रकार, कॉल स्टैक और कुछ प्रमुख चर की स्थिति।

नेटवर्क अनुरोध भेजना, डेटाबेस में लिखना और जटिल क्रमांकन को विलंबित तंत्र में स्थानांतरित किया जाना चाहिए — उदाहरण के लिए, लॉग को फ़ाइल में सहेजें और ऐप के अगले लॉन्च पर भेजें।

क्रैश-रिपोर्टिंग सिस्टम के साथ संयोजन

क्रैश-रिपोर्टिंग सेवाएँ — Firebase Crashlytics, Sentry, Bugsnag — अपना स्वयं का वैश्विक हैंडलर सेट करती हैं। यदि कोई डेवलपर शीर्ष पर एक कस्टम हैंडलर सेट करता है, तो उन्हें अपनी कार्रवाइयों के बाद क्रैश-रिपोर्टिंग सिस्टम को नियंत्रण देना होगा। Android पर हैंडलर संयोजन का उपयोग किया जाता है: अपना तर्क निष्पादित करें, फिर पिछले हैंडलर को कॉल करें।

Firebase Crashlytics के लिए, कस्टम Thread.setDefaultUncaughtExceptionHandler बिल्कुल न सेट करने की अनुशंसा की जाती है — Crashlytics SDK इनिशियलाइज़ेशन पर स्वचालित रूप से ऐसा करता है।

अतिरिक्त जानकारी लॉग करना

उपयोगकर्ता संदर्भ — मानक कॉल स्टैक के अलावा, ऐप संस्करण, OS संस्करण, उपलब्ध मेमोरी आकार और क्रैश से पहले का अपटाइम लॉग करना उपयोगी है। यह डेटा समस्या के पुनरुत्पादन और समाधान के लिए अत्यंत महत्वपूर्ण है।

iOS पर, NSSetUncaughtExceptionHandler का उपयोग न केवल लिखने के लिए बल्कि NSUserDefaults में synchronize फ्लैग के साथ अस्थायी डेटा भंडारण के लिए भी किया जा सकता है — जो तत्काल प्रक्रिया समाप्ति पर भी स्थिरता सुनिश्चित करता है।

रिलीज़ से पहले हैंडलर का परीक्षण

अनिवार्य परीक्षण — Global Exception Handler को CI/CD के प्रत्येक चरण में परीक्षण किया जाना चाहिए। iOS पर, @throw NSException के माध्यम से परीक्षण अपवाद ट्रिगर किया जा सकता है, Android पर — throw RuntimeException() के माध्यम से। सत्यापित करें कि हैंडलर कॉल हुआ, लॉग सहेजा गया और ऐप सही ढंग से समाप्त हुआ।

Google I/O 2023 के अनुसार, उत्पादन में 30% से अधिक क्रैश उन उपकरणों पर होते हैं जिनका डेवलपर ने परीक्षण नहीं किया — विभिन्न Android संस्करण, कस्टम फ़र्मवेयर, सीमित मेमोरी।

हैंडलर का उपयोग करते समय सामान्य गलतियाँ

पहली और सबसे आम गलती — अपवाद को हैंडल करने के बाद ऐप निष्पादन जारी रखने का प्रयास करना। uncaughtException को कॉल करने के बाद, ऐप अस्थिर स्थिति में होता है, और कोई भी आगे के संचालन कैस्केडिंग त्रुटियाँ और डेटा भ्रष्टाचार का कारण बन सकते हैं।

दूसरी गलती — हैंडलर के अंदर लंबे समय तक चलने वाले संचालन करना। नेटवर्क अनुरोध, बड़ी फ़ाइलें लिखना या जटिल गणनाएँ प्रक्रिया के बलपूर्वक समाप्त होने से पहले पूरी नहीं होती हैं। Apple Technical Q&A QA1468 के अनुसार, हैंडलर के अंदर HTTP अनुरोध भेजने का प्रयास खोई हुई क्रैश रिपोर्ट का प्रमुख कारण है।

तीसरी गलती — बैकग्राउंड थ्रेड्स को अनदेखा करना। केवल मुख्य थ्रेड के लिए सेट किया गया Global Exception Handler कोरूटीन, DispatchQueue, AsyncTask या RxJava में क्रैश से रक्षा नहीं करता। Android पर, प्रत्येक थ्रेड का अपना हैंडलर होना चाहिए — और setDefaultUncaughtExceptionHandler केवल व्यक्तिगत हैंडलर के बिना थ्रेड्स के लिए इसे हल करता है।

चौथी गलती — OS सिग्नल के लिए फ़ॉलबैक का अभाव। iOS पर NSSetUncaughtExceptionHandler SIGABRT, SIGSEGV और SIGBUS को नहीं पकड़ता। इन सिग्नल के लिए sigaction API के माध्यम से अलग हैंडलर सेटअप आवश्यक है। डेवलपर्स को इसके बारे में तब पता चलता है जब ऐप बिना किसी क्रैश रिपोर्ट के क्रैश हो जाता है।

पाँचवीं गलती — गोपनीय डेटा लॉग करना। क्रैश लॉग में ईमेल, प्रमाणीकरण टोकन या उपयोगकर्ताओं का व्यक्तिगत डेटा आ सकता है। यह GDPR और Apple App Store Review Guidelines का उल्लंघन करता है। regex या अनुमत फ़ील्ड की व्हाइटलिस्ट के माध्यम से प्रेषित डेटा को हमेशा फ़िल्टर करें।