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

iOS+ Android Flutter Unity

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

सामान्य समस्याएं हल करना/अक्सर पूछे जाने वाले सवाल

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

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

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

Crashlytics आपके ऐप्लिकेशन के सभी इवेंट का विश्लेषण करता है. जैसे, क्रैश, नॉन-फ़ैटल, और एएनआर. साथ ही, इवेंट के ग्रुप बनाता है, जिन्हें समस्याएं कहा जाता है. किसी समस्या में मौजूद सभी इवेंट में, गड़बड़ी की वजह एक ही होती है.

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

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

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

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

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

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

• ज़्यादा काम की चेतावनियां और सिग्नल
  नई समस्या का मतलब है कि नया बग मौजूद है.

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

इन सुधारों को इस तरह रोल आउट किया जा रहा है:

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

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

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

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

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

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

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

• आपने अपने ऐप्लिकेशन में Google Analytics के लिए Firebase SDK टूल जोड़ा है जोड़ा है. Crashlytics SDK टूल के अलावा, यह SDK टूल भी जोड़ना ज़रूरी है.

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

तेज़ गति से लेन बदलने की सूचनाएं नहीं मिल रही हैं

अगर आपको वेलोसिटी अलर्ट नहीं दिख रहे हैं, तो पक्का करें कि आपने इनका इस्तेमाल किया हो: Crashlytics SDK 11.7.0+.

क्रैश से जुड़ी मेट्रिक न दिखना या गलत मेट्रिक दिखना

अगर आपको क्रैश-फ़्री मेट्रिक (जैसे कि क्रैश-फ़्री उपयोगकर्ता और सेशन) नहीं दिख रही हैं या आपको ऐसी मेट्रिक दिख रही हैं जिन पर भरोसा नहीं किया जा सकता, तो यहां दी गई जानकारी देखें:

• पक्का करें कि आपने इन SDK टूल का इस्तेमाल किया हो: Crashlytics SDK 11.7.0+.

• पक्का करें कि डेटा कलेक्शन की सेटिंग, क्रैश-फ़्री मेट्रिक की क्वालिटी पर असर न डाल रही हों:

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

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

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

क्रैश-फ़्री मेट्रिक के बारे में जानें लेख पढ़ें.

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 खाते के ईमेल से लेबल किया जाता है. यह ईमेल पता और नोट, उन सभी प्रोजेक्ट सदस्यों को दिखता है जिनके पास नोट देखने का ऐक्सेस है.

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

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

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

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

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

इंटिग्रेशन

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

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

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

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

पिछली समस्याओं का फिर से दिखना

रिग्रेशन की समस्या क्या होती है?

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

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

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

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics किसी समस्या को रिग्रेशन के तौर पर तब कैटगरी में रखता था, जब वह समस्या ऐप्लिकेशन के किसी भी वर्शन में फिर से होती थी. भले ही, हमें उन ऐप्लिकेशन वर्शन के बारे में तब पता हो, जब आपने समस्या को बंद किया था. इस वजह से, Crashlytics कभी-कभी रिग्रेशन की पहचान गलत तरीके से हो जाती थी. अब हम ऊपर बताए गए कन्वेंशन का इस्तेमाल करते हैं.

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

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

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

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

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

ध्यान दें: फ़रवरी 2022 से पहले, Crashlytics किसी समस्या को रिग्रेशन के तौर पर तब कैटगरी में रखता था, जब वह समस्या किसी भी ऐप्लिकेशन वर्शन में फिर से होती थी. भले ही, हमें उन ऐप्लिकेशन वर्शन के बारे में तब पता हो, जब आपने समस्या को बंद किया था. इस वजह से, Crashlytics कभी-कभी रिग्रेशन की पहचान गलत तरीके से हो जाती है. अब हम ऊपर बताए गए कन्वेंशन का इस्तेमाल करते हैं.

अगर आपको फ़रवरी 2022 से पहले की कई ऐसी रिग्रेशन दिखती हैं जिन्हें गलत तरीके से पहचान लिया गया है, तो उन्हें फिर से बंद किया जा सकता है. इससे वे दोबारा नहीं खुलेंगी.

अनकैच किए गए अपवादों को गंभीर गड़बड़ियों के तौर पर रिपोर्ट करना

Crashlytics, बिना हैंडल किए गए अपवादों को फ़ैटल के तौर पर रिपोर्ट कर सकता है. यह सुविधा, Unity SDK के v10.4.0 से शुरू होती है. यहां दिए गए अक्सर पूछे जाने वाले सवालों से, इस सुविधा को इस्तेमाल करने के पीछे की वजह और सबसे सही तरीकों के बारे में जानने में मदद मिलती है.

किसी ऐप्लिकेशन को, बिना हैंडल किए गए अपवादों की रिपोर्ट फ़ेटल के तौर पर क्यों करनी चाहिए?

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

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

अहम जानकारी: अनकैच किए गए अपवादों को फ़ैटल के तौर पर रिपोर्ट करने से, आपके Android की ज़रूरी जानकारी पर कोई असर नहीं पड़ता. 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 Cloud Diagnostics को मैन्युअल तरीके से भेजनी है, तो Debug.LogException का इस्तेमाल करें. यह विकल्प, पहले विकल्प की तरह Unity कंसोल में अपवाद प्रिंट करता है. हालांकि, यह अपवाद भी दिखाता है (चाहे इसे अब तक दिखाया गया हो या नहीं). यह नॉनलोकल तरीके से गड़बड़ी दिखाता है. इसका मतलब है कि try-catch ब्लॉक के साथ Debug.LogException(exception) का इस्तेमाल करने पर भी, अनकैच किए गए अपवाद का नतीजा मिलता है.

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

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

ध्यान दें कि अगर आपको पकड़े गए अपवाद को 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
    //
}