Crashlytics से जुड़ी समस्या हल करने और अक्सर पूछे जाने वाले सवाल

समस्याएं टेबल में कुछ समस्याओं के लिए अलग-अलग फ़ॉर्मैट (और कभी-कभी "वैरिएंट") देखना

आपको Firebase कंसोल में समस्याएं टेबल में सूची में शामिल समस्याओं के लिए दो अलग-अलग फ़ॉर्मैट दिख सकते हैं. कुछ समस्याओं में आपको "वैरिएंट" नाम की सुविधा भी दिख सकती है. इसकी वजह यह है!

साल 2023 की शुरुआत में, हमने इवेंट का ग्रुप बनाने के लिए, विश्लेषण करने वाला एक बेहतर इंजन लॉन्च किया था. साथ ही, हमने अपडेट किए गए डिज़ाइन और नई समस्याओं (जैसे कि वैरिएंट) के लिए कुछ बेहतर सुविधाएं भी लॉन्च की थीं. ज़्यादा जानकारी के लिए, हमारी हाल ही की ब्लॉग पोस्ट देखें. हालांकि, हाइलाइट के लिए नीचे दी गई जानकारी पढ़ें.

Crashlytics आपके ऐप्लिकेशन के सभी इवेंट (जैसे कि क्रैश, ऐप्लिकेशन बंद होने की समस्या, और ANRs) का विश्लेषण करता है और समस्याओं नाम के इवेंट का ग्रुप बनाता है. किसी समस्या के सभी इवेंट में एक ही वजह से गड़बड़ी होती है.

इवेंट को इन समस्याओं के हिसाब से ग्रुप में बांटने के लिए, बेहतर विश्लेषण इंजन अब इवेंट के कई पहलुओं को देखता है. इनमें स्टैक ट्रेस में मौजूद फ़्रेम, अपवाद मैसेज, गड़बड़ी कोड, और दूसरे प्लैटफ़ॉर्म या गड़बड़ी के प्रकारों की विशेषताएं शामिल हैं.

हालांकि, इवेंट के इस ग्रुप में काम न करने वाले स्टैक ट्रेस अलग हो सकते हैं. किसी अन्य स्टैक ट्रेस का मतलब अलग हो सकता है. किसी समस्या के अंदर इस संभावित अंतर को दिखाने के लिए, अब हम समस्याओं के बीच वैरिएंट बनाते हैं. हर वैरिएंट, किसी समस्या वाले इवेंट का सब-ग्रुप होता है. इसमें एक जैसे फ़ेलियर पॉइंट और एक जैसे स्टैक ट्रेस होते हैं. वैरिएंट की मदद से, किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि क्या गड़बड़ी की वजह अलग-अलग हैं.

इन सुधारों के बाद आपको ये सुविधाएं मिलेंगी:

• समस्या वाली लाइन में दिखाया गया मेटाडेटा में बदलाव किया गया है
  अब अपने ऐप्लिकेशन में समस्याओं को आसानी से समझा जा सकता है और उन्हें प्राथमिकता के हिसाब से व्यवस्थित किया जा सकता है.

• डुप्लीकेट समस्याएं कम होना
  लाइन नंबर में बदलाव करने से नई समस्या नहीं आती है.

• अलग-अलग असल वजहों से होने वाली जटिल समस्याओं को आसानी से डीबग करना
  किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करें.

• ज़्यादा काम की चेतावनियां और सिग्नल
  एक नई समस्या असल में एक नई गड़बड़ी को दिखाती है.

• ज़्यादा असरदार तरीके से खोजने की सुविधा
  हर एक समस्या में, खोजने लायक ज़्यादा मेटाडेटा होता है, जैसे कि अपवाद का टाइप और पैकेज का नाम.

यहां बताया गया है कि इन सुधारों को कैसे लागू किया जा रहा है:

• आपके ऐप्लिकेशन से नए इवेंट मिलने पर, हम जांच करेंगे कि क्या वे मौजूदा समस्या से मेल खाते हैं या नहीं.

• अगर कोई मैच नहीं होता है, तो हम इवेंट में इवेंट को ग्रुप करने वाला हमारा बेहतर एल्गोरिदम अपने-आप लागू कर देंगे. साथ ही, मेटाडेटा के नए डिज़ाइन में नई समस्या आ जाएगी.

अपने इवेंट के ग्रुप में करने के लिए यह पहला बड़ा अपडेट है. अगर आपका कोई सुझाव, शिकायत या राय है या आपको कोई समस्या आती है, तो कृपया शिकायत दर्ज करके हमें बताएं.

क्रैश-फ़्री मेट्रिक और/या रफ़्तार की सूचनाएं नहीं दिख रही हैं

अगर आपको ऐसी मेट्रिक (जैसे कि क्रैश का पता लगाने वाले उपयोगकर्ता और सेशन) और/या वेलोसिटी अलर्ट नहीं दिख रहे हैं जिन पर क्रैश का असर नहीं हुआ है, तो पक्का करें कि

ब्रेडक्रंब लॉग नहीं दिख रहे हैं

अगर आपको ब्रेडक्रंब लॉग नहीं दिख रहे हैं, तो हमारा सुझाव है कि आप Google Analytics के लिए अपने ऐप्लिकेशन के कॉन्फ़िगरेशन की जांच करें. पक्का करें कि आपने इन ज़रूरी शर्तों को पूरा किया हो:

• आपने अपने Firebase प्रोजेक्ट में Google Analytics चालू किया हो.

• आपने Google Analytics के लिए डेटा शेयर करने की सुविधा चालू की हो. Analytics का डेटा शेयर करने की सेटिंग मैनेज करें सेक्शन में जाकर, इस सेटिंग के बारे में ज़्यादा जानें.

• आपने आपके ऐप्लिकेशन में, Google Analytics के लिए Firebase SDK टूल जोड़ा गया है . इस SDK टूल को Crashlytics SDK टूल में के साथ जोड़ा जाना चाहिए.

• Firebase SDK टूल के नए वर्शन ऐप्लिकेशन में इस्तेमाल किए जाने वाले सभी प्रॉडक्ट के लिए.

Crashlytics के डैशबोर्ड में Android ऐप्लिकेशन के लिए, सिम्बॉलिकेट किए गए स्टैक ट्रेस नहीं दिख रहे हैं

अगर Unity IL2CPP की वैल्यू का इस्तेमाल किया जा रहा है और आपको बिना सिम्बॉलिक स्टैक ट्रेस दिख रहे हैं, तो यह तरीका आज़माएं:

1. पक्का करें कि Crashlytics Unity SDK के v8.6.1 या इसके बाद वाले वर्शन का इस्तेमाल किया जा रहा है.

2. पक्का करें कि सिंबल फ़ाइल को जनरेट करने और अपलोड करने के लिए, आपने Firebase CLI crashlytics:symbols:upload कमांड को सेट अप किया हो और उसे इस्तेमाल किया हो.

   जब भी कोई रिलीज़ या कोई बिल्ड बनाते हैं, जिसके लिए आपको Firebase कंसोल में सिंबल वाले स्टैक ट्रेस देखने हैं, तो आपको यह सीएलआई कमांड चलाना होगा. ज़्यादा जानकारी के लिए, पढ़ने लायक क्रैश रिपोर्ट पाएं पेज पर जाएं.

क्या Crashlytics का इस्तेमाल उन ऐप्लिकेशन के साथ किया जा सकता है जो IL2CPP का इस्तेमाल करते हैं?

हां, Crashlytics आपके उन ऐप्लिकेशन के लिए सिम्बॉलिकटेड स्टैक ट्रेस दिखा सकता है जो IL2CPP का इस्तेमाल करते हैं. यह सुविधा Android या Apple प्लैटफ़ॉर्म पर रिलीज़ किए गए ऐप्लिकेशन के लिए उपलब्ध है. यहां बताया गया है कि आपको क्या करना होगा:

1. पक्का करें कि Crashlytics Unity SDK के v8.6.0 या इसके बाद वाले वर्शन का इस्तेमाल किया जा रहा है.

2. अपने प्लैटफ़ॉर्म के लिए ज़रूरी टास्क पूरे करें:

   • Apple प्लैटफ़ॉर्म ऐप्लिकेशन के लिए: किसी खास कार्रवाई की ज़रूरत नहीं है. Apple प्लैटफ़ॉर्म ऐप्लिकेशन के लिए, Firebase Unity Editor प्लगिन आपके Xcode प्रोजेक्ट को सिंबल अपलोड करने के लिए अपने-आप कॉन्फ़िगर करता है.

   • Android ऐप्लिकेशन के लिए: पक्का करें कि सिंबल फ़ाइल को जनरेट करने और अपलोड करने के लिए, आपने Firebase CLI crashlytics:symbols:upload कमांड को सेट अप कर लिया है और उसे इस्तेमाल किया जा रहा है.

     जब भी कोई रिलीज़ या कोई बिल्ड बनाते हैं, जिसके लिए आपको Firebase कंसोल में सिंबल वाले स्टैक ट्रेस देखने हैं, तो आपको यह सीएलआई कमांड चलाना होगा. ज़्यादा जानकारी के लिए, पढ़ने लायक क्रैश रिपोर्ट पाएं पेज पर जाएं.

जिन उपयोगकर्ताओं के ऐप्लिकेशन क्रैश नहीं हुए उनका हिसाब कैसे लगाया जाता है?

क्रैश-फ़्री वैल्यू से, उन उपयोगकर्ताओं का प्रतिशत पता चलता है जो आपके ऐप्लिकेशन से जुड़े, लेकिन किसी खास समयावधि में ऐप्लिकेशन क्रैश नहीं हुआ.

यहां उन उपयोगकर्ताओं के प्रतिशत का हिसाब लगाने का फ़ॉर्मूला दिया गया है जिनके ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं किया गया. इसके इनपुट वैल्यू, Google Analytics से मिलती है.

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• क्रैश होने पर, Google Analytics एक app_exception इवेंट टाइप भेजता है. साथ ही, CRASHED_USERS उस इवेंट टाइप से जुड़े उपयोगकर्ताओं की संख्या दिखाता है.

• Crashlytics डैशबोर्ड के ऊपर दाईं ओर मौजूद ड्रॉप-डाउन मेन्यू से, आपकी चुनी गई समयावधि के दौरान आपके ऐप्लिकेशन से जुड़े रहने वाले उपयोगकर्ताओं की कुल संख्या ALL_USERS दिखती है.

ऐप्लिकेशन के क्रैश होने की समस्या का सामना न करने वाले उपयोगकर्ताओं का प्रतिशत, समय के साथ होने वाले एग्रीगेट के आधार पर निकाला जाता है, न कि औसत के आधार पर.

उदाहरण के लिए, मान लें कि आपके ऐप्लिकेशन में तीन उपयोगकर्ता हैं; हम उन्हें उपयोगकर्ता A, उपयोगकर्ता B, और उपयोगकर्ता C कहेंगे. नीचे दी गई टेबल से पता चलता है कि किन उपयोगकर्ताओं ने हर दिन आपके ऐप्लिकेशन का इस्तेमाल किया और उनमें से किन उपयोगकर्ताओं ने उस दिन ऐप्लिकेशन क्रैश किया:

• बुधवार को, ऐसे उपयोगकर्ताओं का प्रतिशत 50% है जिनके ऐप्लिकेशन बंद नहीं हुए. दूसरे उपयोगकर्ताओं में से 1 उपयोगकर्ता क्रैश नहीं हुआ.
  आपके दो उपयोगकर्ताओं ने बुधवार को आपके ऐप्लिकेशन का इस्तेमाल किया, लेकिन उनमें से सिर्फ़ एक (उपयोगकर्ता B) के डिवाइस में कोई क्रैश नहीं हुआ.

• पिछले दो दिनों में, ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं करने वाले उपयोगकर्ताओं का प्रतिशत 33.3% है. तीन में से 1 उपयोगकर्ता ऐसे हैं जिनके ऐप्लिकेशन क्रैश नहीं हुए.
  पिछले दो दिनों से आपके तीन उपयोगकर्ता आपके ऐप्लिकेशन से जुड़े रहे, लेकिन उनमें से सिर्फ़ एक (उपयोगकर्ता C) के साथ कोई क्रैश नहीं हुआ.

• पिछले तीन दिनों से, ऐसे उपयोगकर्ताओं का प्रतिशत 0% है जिन्हें ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं करना पड़ा. हालांकि, तीन में से 0 उपयोगकर्ता ऐसे थे जिनके ऐप्लिकेशन क्रैश नहीं हुए.
  पिछले तीन दिन से आपके तीन उपयोगकर्ता आपके ऐप्लिकेशन से जुड़े थे, लेकिन इनमें से कोई भी क्रैश नहीं हुआ.

उन उपयोगकर्ताओं की वैल्यू की तुलना अलग-अलग समयावधि में नहीं की जानी चाहिए जिन्हें ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं करना पड़ा. किसी उपयोगकर्ता के क्रैश होने की संभावना उतनी ही ज़्यादा होती है जितनी बार वह आपके ऐप्लिकेशन का इस्तेमाल करता है. इसलिए, हो सकता है कि लंबे समय तक क्रैश-फ़्री उपयोगकर्ताओं की वैल्यू कम हो.

किसी समस्या पर नोट कौन देख सकता है, लिख सकता है, और मिटा सकता है?

नोट की मदद से, प्रोजेक्ट के सदस्य सवाल, स्टेटस अपडेट वगैरह से जुड़ी खास समस्याओं पर टिप्पणी कर सकते हैं.

जब प्रोजेक्ट का कोई सदस्य कोई नोट पोस्ट करता है, तो उस पर उसके Google खाते के ईमेल का लेबल दिखता है. यह ईमेल पता नोट के साथ उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस होता है.

नोट को देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में यहां बताया गया है:

• प्रोजेक्ट के ऐसे सदस्य जिन्हें इनमें से कोई भी भूमिका असाइन की गई है वे मौजूदा नोट देख और मिटा सकते हैं. साथ ही, किसी समस्या पर नए नोट लिख सकते हैं.

  • प्रोजेक्ट के मालिक या एडिटर, Firebase का एडमिन, क्वालिटी एडमिन या Crashlytics का एडमिन

• प्रोजेक्ट के ऐसे सदस्य जो इनमें से कोई भी भूमिका रखते हैं, वे किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे नोट मिटा या लिख नहीं सकते.

  • प्रोजेक्ट व्यूअर, Firebase व्यूअर, क्वालिटी व्यूअर या Crashlytics व्यूअर

जिन उपयोगकर्ताओं के ऐप्लिकेशन क्रैश नहीं हुए उनका हिसाब कैसे लगाया जाता है?

क्रैश-फ़्री मेट्रिक के बारे में समझना देखें.

किसी समस्या पर नोट कौन देख सकता है, लिख सकता है, और मिटा सकता है?

नोट की मदद से, प्रोजेक्ट के सदस्य सवाल, स्टेटस अपडेट वगैरह से जुड़ी खास समस्याओं पर टिप्पणी कर सकते हैं.

जब प्रोजेक्ट का कोई सदस्य कोई नोट पोस्ट करता है, तो उस पर उसके Google खाते के ईमेल का लेबल दिखता है. यह ईमेल पता नोट के साथ उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस होता है.

नोट को देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में यहां बताया गया है:

• प्रोजेक्ट के ऐसे सदस्य जिन्हें इनमें से कोई भी भूमिका असाइन की गई है वे मौजूदा नोट देख और मिटा सकते हैं. साथ ही, किसी समस्या पर नए नोट लिख सकते हैं.

  • प्रोजेक्ट के मालिक या एडिटर, Firebase का एडमिन, क्वालिटी एडमिन या Crashlytics का एडमिन

• प्रोजेक्ट के ऐसे सदस्य जो इनमें से कोई भी भूमिका रखते हैं, वे किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे नोट मिटा या लिख नहीं सकते.

  • प्रोजेक्ट व्यूअर, Firebase व्यूअर, क्वालिटी व्यूअर या Crashlytics व्यूअर

ऐप्लिकेशन, Google Mobile Ads SDK का भी इस्तेमाल करता है, लेकिन क्रैश नहीं होता

अगर आपके प्रोजेक्ट में Google Mobile Ads SDK के साथ Crashlytics का इस्तेमाल किया जाता है, तो हो सकता है कि अपवाद हैंडलर को रजिस्टर करते समय क्रैश रिपोर्टर रुकावट डाल रहे हों. समस्या को ठीक करने के लिए, disableSDKCrashReporting पर कॉल करके Mobile Ads SDK में क्रैश रिपोर्टिंग को बंद करें.

मेरा BigQuery डेटासेट कहां मौजूद है?

Crashlytics को BigQuery से लिंक करने के बाद, आपके बनाए गए नए डेटासेट, अमेरिका में अपने-आप सेव हो जाते हैं. इस बात से कोई फ़र्क़ नहीं पड़ता कि आपका Firebase प्रोजेक्ट कहां मौजूद है.

समस्या क्या है?

जब आपने किसी समस्या को पहले ही बंद कर दिया था, तब भी उस समस्या का रिग्रेशन होता है. हालांकि, Crashlytics को एक नई रिपोर्ट मिलती है कि यह समस्या फिर से आ गई है. Crashlytics से, वापस आने वाली इन समस्याओं को अपने-आप फिर से खोला जाता है, ताकि आप इन्हें अपने ऐप्लिकेशन के हिसाब से ठीक कर सकें.

यहां एक उदाहरण दिया गया है, जिसमें बताया गया है कि Crashlytics किसी समस्या को रिग्रेशन की कैटगरी में कैसे बांटता है:

1. Crashlytics को पहली बार क्रैश “A” की क्रैश रिपोर्ट मिली है. Crashlytics से, उस क्रैश से जुड़ी समस्या (समस्या "A") को खोलने में मदद मिलती है.
2. इस गड़बड़ी को जल्दी ठीक करें, समस्या "A" को बंद करें, और फिर अपने ऐप्लिकेशन का नया वर्शन रिलीज़ करें.
3. जब आपने समस्या हल कर ली होती है, तब Crashlytics को समस्या "A" के बारे में दूसरी रिपोर्ट मिलती है.
   • अगर रिपोर्ट, ऐप्लिकेशन के किसी ऐसे वर्शन से है जिसके बारे में Crashlytics को पता है कि आपने समस्या को बंद किया था. इसका मतलब है कि वर्शन ने किसी भी क्रैश के लिए क्रैश रिपोर्ट भेजी थी, तो Crashlytics को यह नहीं दिखेगा कि समस्या को वापस लिया गया है. समस्या बंद ही रहेगी.
   • अगर रिपोर्ट ऐप्लिकेशन के किसी ऐसे वर्शन से है जिसे Crashlytics से बंद नहीं किया गया है (इसका मतलब है कि वर्शन ने किसी भी क्रैश के लिए, कभी कोई कोई क्रैश रिपोर्ट नहीं भेजी है), तो Crashlytics यह मानता है कि समस्या ठीक की जा चुकी है और वह इसे फिर से खोलेगा.

जब कोई समस्या वापस आती है, तो हम एक रिग्रेशन सिग्नल की चेतावनी भेजते हैं और उसमें एक रिग्रेशन सिग्नल जोड़ते हैं. इससे आपको पता चलता है कि Crashlytics ने समस्या को फिर से ठीक कर दिया है. अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से समस्या को फिर से नहीं दिखाना है, तो समस्या को बंद करने के बजाय उसे "म्यूट" करें.

मुझे ऐप्लिकेशन के पुराने वर्शन के लिए, वापस आने वाली समस्याएं क्यों दिख रही हैं?

अगर कोई रिपोर्ट ऐप्लिकेशन के किसी पुराने वर्शन की है, जिसने समस्या को बंद करते समय कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics समस्या को वापस समस्या के तौर पर रखता है और समस्या को फिर से खोलेगा.

यह स्थिति नीचे दी गई स्थिति में हो सकती है: आपने गड़बड़ी ठीक कर दी है और अपने ऐप्लिकेशन का एक नया वर्शन रिलीज़ किया है, लेकिन आपके पास अब भी ऐसे उपयोगकर्ता हैं जो गड़बड़ी को ठीक किए बिना पुराने वर्शन का इस्तेमाल कर रहे हैं. अगर, संयोग से, उन पुराने वर्शन में से किसी ने समस्या को बंद करते समय कोई भी क्रैश रिपोर्ट कभी नहीं भेजी थी और उन उपयोगकर्ताओं को गड़बड़ी का सामना करना पड़ता है, तो वे क्रैश रिपोर्ट एक वापस आकर ट्रिगर होने वाली समस्या को ट्रिगर करेंगी.

अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से समस्या को फिर से नहीं खोलना है, तो समस्या को बंद करने के बजाय, "म्यूट करें".

ऐप्लिकेशन को उन अपवादों को जानलेवा के तौर पर क्यों रिपोर्ट करना चाहिए जिनके बारे में पता नहीं चल पाया है?

ऐसे अपवादों को घातक के तौर पर रिपोर्ट करने से, आपको इस बात का साफ़ तौर पर पता चलता है कि किन अपवादों की वजह से, गेम नहीं चलाया जा सकता – भले ही, ऐप्लिकेशन चलता रहे.

ध्यान दें कि अगर नुकसान पहुंचाने वाले ऐप्लिकेशन की जानकारी दी जाती है, तो ऐसे उपयोगकर्ताओं (सीएफ़यू) का प्रतिशत कम हो सकता है जिन्हें ऐप्लिकेशन क्रैश होने की समस्या का सामना नहीं करना पड़ा. हालांकि, सीएफ़यू मेट्रिक से आपको पता चलेगा कि ऐप्लिकेशन के असली उपयोगकर्ताओं को कैसा अनुभव मिलेगा.

किन अपवादों को जानलेवा माना जाएगा?

Crashlytics से, किसी अपवाद को जानलेवा साबित करने के लिए, इन दोनों शर्तों को पूरा करना ज़रूरी है:

• अपने ऐप्लिकेशन में शुरू करने के दौरान, ReportUncaughtExceptionsAsFatal प्रॉपर्टी को true पर सेट किया जाना चाहिए.

• आपके ऐप्लिकेशन (या किसी लाइब्रेरी के साथ) में ऐसा अपवाद दिखता है जो नहीं पकड़ा गया. अगर किसी अपवाद को बनाया गया है, लेकिन फेंका नहीं गया है, तो इसे पकड़ में न आने वाला नहीं माना जाता है.

जांच में नहीं मिले अपवादों को जानलेवा के तौर पर रिपोर्ट करने की सुविधा चालू करने के बाद, अब मेरे पास कई मौतें भी हैं. मैं इन अपवादों को सही तरीके से कैसे हैंडल करूं?

जब आपको उन अपवादों की रिपोर्ट मिलने लगे, जिन्हें पता नहीं चल पाया है और आपको नुकसान पहुंचाने वाले अपवादों के बारे में शिकायत मिलने लगती है, तब इन अपवादों से निपटने के कुछ तरीके यहां दिए गए हैं:

• ध्यान दें कि इन अपवादों को समझने और उनसे निपटने का तरीका क्या है.
• Unity डीबग कंसोल और Crashlytics से जुड़े अपवादों को लॉग करने के लिए, अलग-अलग विकल्पों का इस्तेमाल करें.

थके हुए अपवादों को पकड़ना और मैनेज करना

अचानक या असाधारण स्थितियों को दिखाने के लिए, अपवाद बनाए और इस्तेमाल किए जाते हैं. किसी अपवाद की वजह से दिखने वाली समस्याओं को हल करने के लिए, प्रोग्राम को पहले से तय स्थिति में वापस कर दिया जाता है. इस प्रोसेस को अपवाद हैंडलिंग कहा जाता है.

सबसे अच्छा तरीका यह है कि सभी अनुमानित अपवादों को पकड़ कर हैंडल किया जाए, बशर्ते प्रोग्राम को तय की गई स्थिति में वापस न लाया जा सके.

यह कंट्रोल करने के लिए कि किस तरह के अपवादों को किस कोड की मदद से पकड़ा और मैनेज किया जाता है, वह रैप कोड जो try-catch ब्लॉक में अपवाद जनरेट कर सकता है. पक्का करें कि catch स्टेटमेंट की शर्तें उतनी छोटी हों, जितनी खास अपवादों को सही तरीके से मैनेज करने के लिए संभव हों.

Unity या Crashlytics में अपवादों को लॉग करना

Unity या Crashlytics में, अपवादों को रिकॉर्ड करने के कई तरीके हैं, ताकि समस्या को डीबग किया जा सके.

Crashlytics का इस्तेमाल करते समय, आम तौर पर इस्तेमाल किए जाने वाले और सुझाए गए दो विकल्प यहां दिए गए हैं:

• पहला विकल्प: Unity कंसोल में प्रिंट करें, लेकिन डेवलपमेंट या समस्या हल करने के दौरान Crashlytics को रिपोर्ट न करें.

  • Debug.Log(exception), Debug.LogWarning(exception), और Debug.LogError(exception) का इस्तेमाल करके Unity कंसोल पर प्रिंट करें. यह अपवाद के कॉन्टेंट को Unity कंसोल पर प्रिंट करता है और अपवाद को फिर से नहीं दिखाता.

• दूसरा विकल्प: इन स्थितियों के लिए, Crashlytics डैशबोर्ड पर Crashlytics पर अपलोड करें और रिपोर्ट की सभी जानकारी एक जगह पर पाएं:

  • अगर Crashlytics के बाद के किसी इवेंट को डीबग करने के लिए आपको एक अपवाद लॉग करना है, तो Crashlytics.Log(exception.ToString()) का इस्तेमाल करें.
  • अगर किसी अपवाद को पहचानने और मैनेज करने के बाद भी, Crashlytics को इसकी शिकायत की जानी चाहिए, तो इसे नुकसान न पहुंचाने वाले इवेंट के तौर पर लॉग करने के लिए Crashlytics.LogException(exception) का इस्तेमाल करें.

हालांकि, अगर आपको मैन्युअल तरीके से Unity क्लाउड डाइग्नोस्टिक्स को किसी बड़ी घटना की शिकायत करनी है, तो Debug.LogException का इस्तेमाल करें. यह विकल्प, Unity कंसोल पर, विकल्प 1 की तरह अपवाद को प्रिंट करता है. हालांकि, यह अपवाद को भी दिखाता है (चाहे इसे अभी तक फेंका या पकड़ा गया हो या नहीं). यह गड़बड़ी को स्थानीय तौर पर नहीं दिखाता है. इसका मतलब है कि try-catch ब्लॉक के साथ आस-पास के Debug.LogException(exception) पर भी, ऐसा अपवाद मिलता है जिसकी पहचान नहीं की जा सकी.

इसलिए, Debug.LogException को तब कॉल करें, अगर आपको नीचे दिए गए सभी काम करने हों:

• Unity कंसोल के लिए अपवाद को प्रिंट करने के लिए.
• अपवाद को जानलेवा इवेंट के तौर पर अपलोड करने के लिए, Crashlytics का इस्तेमाल करें.
• अपवाद के तौर पर, यह अपवाद नहीं माना गया है और Unity Cloud डाइग्नोस्टिक्स को रिपोर्ट भी दी जाती है.

ध्यान दें कि अगर आपको Unity कंसोल के लिए कैप्चर किए गए अपवाद को प्रिंट करना है और Crashlytics पर अपलोड करना है, तो यह नुकसान न पहुंचाने वाले इवेंट के तौर पर करें:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}