Crashlytics से जुड़ी समस्या हल करने और अक्सर पूछे जाने वाले सवाल
इस पेज पर, समस्या हल करने से जुड़ी सहायता और Crashlytics इस्तेमाल करने के बारे में अक्सर पूछे जाने वाले सवालों के जवाब दिए गए हैं. अगर आपको जो जानकारी चाहिए वह नहीं मिल रही या कोई और मदद चाहिए, तो Firebase की सहायता टीम से संपर्क करें.
सामान्य समस्याएं हल करना/अक्सर पूछे जाने वाले सवाल
समस्याएं टेबल में कुछ समस्याओं के लिए अलग-अलग फ़ॉर्मैट
(और कभी-कभी "वैरिएंट") देखना
आपको Firebase कंसोल में, समस्याएं टेबल में दी गई समस्याओं के लिए दो अलग-अलग फ़ॉर्मैट दिख सकते हैं. आपको अपनी कुछ समस्याओं में "वैरिएंट" नाम की सुविधा भी दिख सकती है. इसकी वजह यह है!
साल 2023 की शुरुआत में, हमने इवेंट को ग्रुप करने के लिए, बेहतर विश्लेषण इंजन लॉन्च किया था. साथ ही, हमने इसका अपडेट किया गया डिज़ाइन और नई समस्याओं (जैसे, वैरिएंट!) के लिए कुछ ऐडवांस सुविधाएं भी लॉन्च की थीं. पूरी जानकारी के लिए, हमारी हाल की ब्लॉग पोस्ट देखें. हालांकि, यहां दी गई हाइलाइट के बारे में पढ़ें.
Crashlytics, आपके ऐप्लिकेशन के सभी इवेंट का विश्लेषण करता है. जैसे, क्रैश, नुकसान न पहुंचाने वाली समस्याएं, और ANR वाली गड़बड़ियां. साथ ही, यह समस्याएं नाम के इवेंट के ग्रुप बनाता है. किसी समस्या में सभी इवेंट एक ही वजह से फ़ेल हो जाते हैं.
इवेंट को इन समस्याओं के हिसाब से ग्रुप करने के लिए, बेहतर विश्लेषण इंजन अब इवेंट के कई पहलुओं पर ध्यान देता है. इनमें स्टैक ट्रेस में फ़्रेम, अपवाद मैसेज, गड़बड़ी कोड, और दूसरे प्लैटफ़ॉर्म या गड़बड़ी के टाइप से जुड़ी विशेषताएं शामिल हैं.
हालांकि, इवेंट के इस ग्रुप में, गड़बड़ी की वजह बनने वाले स्टैक ट्रेस अलग हो सकते हैं. अगर स्टैक ट्रेस अलग है, तो इसकी अलग वजह हो सकती है.
किसी समस्या में इस संभावित अंतर को दिखाने के लिए, अब हम समस्याओं में वैरिएंट बनाते हैं. हर वैरिएंट, किसी समस्या में इवेंट का एक सब-ग्रुप होता है, जिसमें फ़ेलियर पॉइंट और एक जैसा स्टैक ट्रेस होता है. वैरिएंट की मदद से,
किसी समस्या में मौजूद सबसे सामान्य स्टैक ट्रेस को डीबग किया जा सकता है. साथ ही, यह पता लगाया जा सकता है कि क्या अलग-अलग मुख्य वजहों से गड़बड़ी हो रही है.
इन सुधारों से आपको मिलने वाले फ़ायदों के बारे में यहां बताया गया है:
समस्या वाली लाइन में बेहतर मेटाडेटा दिखाया गया है अब आपके ऐप्लिकेशन में होने वाली समस्याओं को समझना और उन्हें प्राथमिकता के हिसाब से निपटाना आसान हो गया है.
डुप्लीकेट समस्याएं कम होंगी लाइन नंबर बदलने पर, नई समस्या नहीं आती.
अलग-अलग मूल वजहों से, जटिल समस्याओं को आसानी से डीबग करने की सुविधा किसी समस्या में मौजूद सबसे आम स्टैक ट्रेस को डीबग करने के लिए, वैरिएंट का इस्तेमाल करना.
ज़्यादा काम की सूचनाएं और सिग्नल एक नई समस्या, असल में एक नई गड़बड़ी दिखाती है.
ज़्यादा असरदार खोज हर समस्या में ऐसा मेटाडेटा होता है जिसे खोजा जा सके, जैसे कि अपवाद का टाइप और पैकेज का नाम.
इन सुधारों के रोल आउट होने का तरीका यहां बताया गया है:
आपके ऐप्लिकेशन से नए इवेंट मिलने पर, हम जांच करेंगे कि वे किसी मौजूदा समस्या से मेल खाते हैं या नहीं.
अगर कोई मैच नहीं होता है, तो हम अपने बेहतर इवेंट-ग्रुपिंग एल्गोरिदम को अपने-आप इवेंट पर लागू कर देंगे. इसके बाद, नए मेटाडेटा डिज़ाइन के साथ नई समस्या शुरू कर दी जाएगी.
यह पहला बड़ा अपडेट है, जिसे हम अपने इवेंट के ग्रुप में लागू कर रहे हैं. अगर आपको कोई सुझाव/राय देनी है या शिकायत करनी है या कोई समस्या आती है, तो कृपया
शिकायत दर्ज करके
हमें बताएं.
क्रैश-फ़्री मेट्रिक और/या वेलोसिटी अलर्ट नहीं दिख रहे हैं
अगर आपको क्रैश-फ़्री मेट्रिक (जैसे, बिना क्रैश वाले उपयोगकर्ता और सेशन) और/या वेलोसिटी अलर्ट नहीं दिख रहे हैं, तो पक्का करें कि
ब्रेडक्रंब लॉग नहीं दिख रहे हैं
अगर आपको ब्रेडक्रंब लॉग नहीं दिख रहा है, तो हमारा सुझाव है कि आप Google Analytics के लिए अपने ऐप्लिकेशन के कॉन्फ़िगरेशन की जांच करें.
पक्का करें कि आपने ये ज़रूरी शर्तें पूरी की हों:
Crashlytics के डैशबोर्ड में, Android ऐप्लिकेशन के लिए
सिम्बॉलिकेट नहीं किए गए स्टैक ट्रेस दिखते हैं
अगर Unity IL2CPP
का इस्तेमाल किया जा रहा है और आपको बिना सिंबल वाले स्टैक ट्रेस दिख रहे हैं, तो यह तरीका आज़माएं:
पक्का करें कि Crashlytics Unity SDK के v8.6.1 या इसके बाद वाले वर्शन का इस्तेमाल किया जा रहा है.
पक्का करें कि आपने अपने सिंबल वाली फ़ाइल को जनरेट और अपलोड करने के लिए, Firebase CLI
crashlytics:symbols:upload कमांड को सेट अप किया हो और उसे चलाया हो.
अगर आप कोई रिलीज़ बिल्ड या कोई ऐसा बिल्ड बनाते हैं जिसके लिए आप Firebase कंसोल में सिम्बॉलिकेट किए गए स्टैक ट्रेस देखना चाहते हैं, तो आपको हर बार इस सीएलआई कमांड को चलाना होगा. ज़्यादा जानने के लिए, क्रैश रिपोर्ट ऐक्सेस करें पेज पर जाएं. इस पेज पर, आसानी से पढ़ी जा सकने वाली क्रैश रिपोर्ट पाएं.
क्या Crashlytics का इस्तेमाल, IL2CPP का इस्तेमाल करने वाले ऐप्लिकेशन के साथ किया जा सकता है?
हां, Crashlytics का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, सिम्बॉलिकेट
वाले स्टैक ट्रेस दिखाए जा सकते हैं. ऐसा उन ऐप्लिकेशन के लिए किया जाता है जो IL2CPP का इस्तेमाल करते हैं. यह सुविधा, Android या Apple
प्लैटफ़ॉर्म पर रिलीज़ किए गए ऐप्लिकेशन के लिए उपलब्ध है. यहां बताया गया है कि आपको क्या करना होगा:
पक्का करें कि Crashlytics Unity SDK के v8.6.0 या इसके बाद वाले वर्शन का इस्तेमाल किया जा रहा है.
अपने प्लैटफ़ॉर्म के लिए ज़रूरी टास्क पूरे करें:
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 उस इवेंट टाइप से जुड़े उपयोगकर्ताओं की संख्या दिखाता है.
ALL_USERS, उस समयावधि में आपके ऐप्लिकेशन से जुड़े कुल उपयोगकर्ताओं की संख्या दिखाता है. इस समयावधि को आपने Crashlytics डैशबोर्ड के ऊपर दाईं ओर मौजूद ड्रॉप-डाउन मेन्यू से चुना है.
जिन उपयोगकर्ताओं ने ऐप्लिकेशन क्रैश नहीं किया है उनका प्रतिशत समय के साथ इकट्ठा होने वाला है, न कि औसत.
उदाहरण के लिए, मान लें कि आपके ऐप्लिकेशन के तीन उपयोगकर्ता हैं; हम उन्हें उपयोगकर्ता A, उपयोगकर्ता B,
और उपयोगकर्ता C कहेंगे. इस टेबल से पता चलता है कि हर दिन कौनसे उपयोगकर्ता आपके ऐप्लिकेशन से जुड़े और
उन उपयोगकर्ताओं में से किन उपयोगकर्ताओं का ऐप्लिकेशन क्रैश हुआ:
सोमवार
मंगलवार
बुधवार
आपके ऐप्लिकेशन से जुड़े उपयोगकर्ता
A, B, C
A, B, C
A, B
वह उपयोगकर्ता जिसका ऐप्लिकेशन क्रैश हो गया था
C
B
A
बुधवार को, आपके ऐप्लिकेशन को इस्तेमाल करने वाले लोगों का प्रतिशत 50% है. (2 में से 1 उपयोगकर्ता
क्रैश-फ़्री था). आपके दो उपयोगकर्ताओं ने बुधवार को आपके ऐप्लिकेशन का इस्तेमाल किया, लेकिन उनमें से सिर्फ़ एक (उपयोगकर्ता B) को कोई क्रैश नहीं हुआ.
पिछले दो दिनों में, उन उपयोगकर्ताओं का प्रतिशत 33.3% है जिन्हें ऐप्लिकेशन क्रैश नहीं हुआ. तीन में से 1 उपयोगकर्ता ने ऐप्लिकेशन क्रैश नहीं किया. पिछले दो दिनों में आपके तीन उपयोगकर्ता आपके ऐप्लिकेशन से जुड़े, लेकिन उनमें से सिर्फ़ एक (उपयोगकर्ता C) को कोई क्रैश नहीं हुआ.
पिछले तीन दिनों में, उन उपयोगकर्ताओं का प्रतिशत 0% है जिन्हें ऐप्लिकेशन क्रैश नहीं हुआ. तीन में से कोई भी उपयोगकर्ता क्रैश नहीं हुआ. पिछले तीन दिनों में, आपके तीन उपयोगकर्ता आपके ऐप्लिकेशन से जुड़े. हालांकि, उनमें से किसी भी उपयोगकर्ता को कोई क्रैश नहीं मिला.
उन उपयोगकर्ताओं के मान की तुलना अलग-अलग समयावधि के दौरान नहीं की जानी चाहिए जिन पर ऐप्लिकेशन क्रैश नहीं हुआ.
किसी एक उपयोगकर्ता को क्रैश का अनुभव होने की संभावना जितनी बार
आपके ऐप्लिकेशन का इस्तेमाल करती है उतनी बार होती जाती है. इसलिए, लंबी अवधि के लिए,
ऐसे उपयोगकर्ताओं की वैल्यू कम हो सकती है जिनके ऐप्लिकेशन में क्रैश नहीं हुआ है.
किसी समस्या पर नोट कौन देख सकता है, लिख सकता है, और मिटा सकता है?
नोट की मदद से प्रोजेक्ट के सदस्य, कुछ समस्याओं पर टिप्पणी कर सकते हैं. जैसे, सवाल, स्टेटस अपडेट वगैरह.
जब प्रोजेक्ट का कोई सदस्य नोट पोस्ट करता है, तो वह नोट उसके Google खाते के ईमेल पते से लेबल हो जाता है. यह ईमेल पता, प्रोजेक्ट के उन सभी सदस्यों को नोट के साथ दिखता है जिनके पास नोट को देखने का ऐक्सेस होता है.
यहां नोट को देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में बताया गया है:
जिन प्रोजेक्ट के सदस्य इनमें से किसी भी भूमिका में हैं वे मौजूदा नोट देख और मिटा सकते हैं. साथ ही, वे किसी समस्या पर नए नोट भी लिख सकते हैं.
प्रोजेक्ट के ऐसे सदस्य जिन्हें इनमें से कोई भी भूमिका दी गई है, वे किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे कोई नोट मिटा या लिख नहीं सकते.
किसी समस्या पर नोट कौन देख सकता है, लिख सकता है, और मिटा सकता है?
नोट की मदद से प्रोजेक्ट के सदस्य, कुछ समस्याओं पर टिप्पणी कर सकते हैं. जैसे, सवाल, स्टेटस अपडेट वगैरह.
जब प्रोजेक्ट का कोई सदस्य नोट पोस्ट करता है, तो वह नोट उसके Google खाते के ईमेल पते से लेबल हो जाता है. यह ईमेल पता, प्रोजेक्ट के उन सभी सदस्यों को नोट के साथ दिखता है जिनके पास नोट को देखने का ऐक्सेस होता है.
यहां नोट को देखने, लिखने, और मिटाने के लिए ज़रूरी ऐक्सेस के बारे में बताया गया है:
जिन प्रोजेक्ट के सदस्य इनमें से किसी भी भूमिका में हैं वे मौजूदा नोट देख और मिटा सकते हैं. साथ ही, वे किसी समस्या पर नए नोट भी लिख सकते हैं.
प्रोजेक्ट के ऐसे सदस्य जिन्हें इनमें से कोई भी भूमिका दी गई है, वे किसी समस्या पर पोस्ट किए गए नोट देख सकते हैं. हालांकि, वे कोई नोट मिटा या लिख नहीं सकते.
ऐप्लिकेशन में
Google Mobile Ads SDK का भी इस्तेमाल होता है, लेकिन क्रैश नहीं हो रहे
अगर आपके प्रोजेक्ट में Google Mobile Ads SDK के साथ-साथ Crashlytics का इस्तेमाल किया जाता है, तो हो सकता है कि क्रैश रिपोर्टर, अपवाद हैंडलर को रजिस्टर करते समय रुकावट डाल रहे हों. इस समस्या को हल करने के लिए, Mobile Ads SDK में disableSDKCrashReporting पर कॉल करके क्रैश रिपोर्टिंग को बंद करें.
मेरा BigQuery डेटासेट कहां है?
Crashlytics को BigQuery से लिंक करने के बाद, आपके बनाए गए नए डेटासेट अपने-आप अमेरिका में मौजूद हो जाते हैं. भले ही, आपका Firebase प्रोजेक्ट किसी भी जगह पर हो.
ऐसी समस्याएं जिनका समाधान नहीं हुआ है
रिग्रेशन
की समस्या क्या है?
जब आपने पहले समस्या को बंद कर दिया था, तब उसमें एक समस्या का रिग्रेशन हुआ हो. हालांकि,
Crashlytics को एक नई रिपोर्ट मिलती है कि यह समस्या फिर से आई है.
Crashlytics, वापस आने वाली इन समस्याओं को अपने-आप दोबारा खोलता है, ताकि आप
अपने ऐप्लिकेशन के हिसाब से उन्हें ठीक कर सकें.
यहां उदाहरण के तौर पर एक उदाहरण दिया गया है. इसमें बताया गया है कि Crashlytics, किसी समस्या को रिग्रेशन की कैटगरी में कैसे बांटता है:
पहली बार, Crashlytics को क्रैश
"A" के बारे में क्रैश रिपोर्ट मिली है. Crashlytics से, क्रैश से जुड़ी समस्या (समस्या "A") खुलती है.
इस गड़बड़ी को तुरंत ठीक किया जाता है, समस्या "A" को बंद किया जाता है, और
अपने ऐप्लिकेशन का नया वर्शन रिलीज़ किया जाता है.
जब आप समस्या को बंद कर देते हैं, तो Crashlytics को समस्या "A" के बारे में एक और रिपोर्ट मिलती है.
अगर रिपोर्ट किसी ऐप्लिकेशन के ऐसे वर्शन की है जिसके बारे में Crashlytics को किसी समस्या को ठीक करने के बारे में जानकारी है (यानी कि वर्शन ने किसी भी क्रैश के लिए, क्रैश रिपोर्ट भेजी थी, तो Crashlytics, समस्या को वापस आने वाली समस्या नहीं मानेगा. समस्या बंद रहेगी.
अगर रिपोर्ट किसी ऐप्लिकेशन के ऐसे वर्शन की है जिसके बारे में Crashlytics को समस्या बंद करने के बारे में नहीं पता है (यानी कि वर्शन ने किसी भी क्रैश के लिए कभी भीकोई क्रैश रिपोर्ट नहीं भेजी है), तो Crashlytics, समस्या के ठीक होने के बारे में मानेगा और समस्या को दोबारा शुरू कर देगा.
जब किसी समस्या के वापस आने पर, हम उसे रिग्रेशन की चेतावनी भेजते हैं और समस्या के साथ एक रिग्रेशन सिग्नल जोड़ते हैं. इससे आपको पता चलता है कि Crashlytics ने समस्या को फिर से खोल दिया है. अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से, किसी समस्या को फिर से खोलना नहीं है, तो समस्या को बंद करने के बजाय "म्यूट करें" विकल्प चुनें.
मुझे ऐप्लिकेशन के पुराने वर्शन के लिए, वापस आने वाली समस्याएं
क्यों दिख रही हैं?
अगर कोई रिपोर्ट ऐप्लिकेशन के किसी पुराने वर्शन की है, जिसने समस्या को बंद करने के समय कभी भी कोई क्रैश रिपोर्ट नहीं भेजी थी, तो Crashlytics, समस्या के ठीक होने के बारे में मानेगा और समस्या को फिर से खोलेगा.
ऐसा नीचे दी गई स्थिति में हो सकता है: आपने कोई गड़बड़ी ठीक की है और
अपने ऐप्लिकेशन का नया वर्शन रिलीज़ किया है, लेकिन उपयोगकर्ता अब भी बिना गड़बड़ी के
पुराने वर्शन का इस्तेमाल कर रहे हैं. अगर समस्या की वजह से, उन क्रैश रिपोर्ट में से किसी एक ने समस्या को बंद किए जाने के बाद भी कभी भी कोई क्रैश रिपोर्ट नहीं भेजी और उन उपयोगकर्ताओं को गड़बड़ी मिली, तो फिर उन क्रैश रिपोर्ट से वापस आने वाली समस्या ट्रिगर होगी.
अगर आपको हमारे रिग्रेशन एल्गोरिदम की वजह से, किसी समस्या के बारे में फिर से जानकारी नहीं देनी है, तो समस्या को बंद करने के बजाय "म्यूट करें" विकल्प चुनें.
जिन अपवादों की जानकारी नहीं मिली है उनकी शिकायत गंभीर के तौर पर करना
Crashlytics, किसी ऐसे अपवाद को गंभीर के तौर पर रिपोर्ट कर सकता है जिसकी पहचान न हो सकी हो. यह रिपोर्ट, Unity SDK टूल के v10.4.0
से शुरू होती है. नीचे दिए गए अक्सर पूछे जाने वाले सवालों से, इस सुविधा का इस्तेमाल करने की वजह और सबसे सही तरीकों को समझने में मदद मिलती है.
किसी ऐप्लिकेशन को जिन अपवादों की पहचान नहीं हुई है उन्हें गंभीर के तौर पर क्यों रिपोर्ट करना चाहिए?
जिन अपवादों को पकड़ा नहीं गया है उन्हें गंभीर नुकसान के तौर पर रिपोर्ट करने से, आपको इस बात का सटीक संकेत मिलता है कि किन अपवादों की वजह से गेम नहीं चल सकता – भले ही, ऐप्लिकेशन लगातार चल रहा हो.
ध्यान दें कि अगर किसी नुकसान की जानकारी देने वाली रिपोर्ट शुरू की जाती है, तो आपका ऐप्लिकेशन इस्तेमाल न करने वाले उपयोगकर्ताओं (सीएफ़यू) के प्रतिशत में कमी आ सकती है. हालांकि, सीएफ़यू मेट्रिक से यह पता चलेगा कि आपके ऐप्लिकेशन का इस्तेमाल करने वाले असली उपयोगकर्ताओं को कैसा अनुभव मिलेगा.
किन अपवादों को गंभीर नुकसान
के तौर पर रिपोर्ट किया जाएगा?
Crashlytics से, किसी ऐसे अपवाद को गंभीर के तौर पर रिपोर्ट किया जा सकता है जिसकी पहचान नहीं हो पाई है. इसके लिए, इन दोनों शर्तों को पूरा करना ज़रूरी है:
आपका ऐप्लिकेशन (या शामिल की गई लाइब्रेरी) एक ऐसा अपवाद देता है जिसे खोजा नहीं जा सका. एक ऐसा अपवाद है जिसे बनाया नहीं गया है, लेकिन उसकी नकल नहीं की गई है, लेकिन इसे अनदेखा नहीं किया गया है.
जिन अपवादों की जानकारी मौजूद नहीं है उन्हें गंभीर नुकसान पहुंचाने वाली रिपोर्ट की सुविधा चालू करने के बाद, अब मेरे पास कई नए मामले हैं. मैं इन अपवादों का अच्छी तरह से कैसे इस्तेमाल करूं?
जब आपको किसी ऐसे अपवाद की शिकायत गंभीर के तौर पर मिलने लगती है जिसकी पहचान न हुई हो, तो इन अपवादों से निपटने के कुछ तरीके यहां दिए गए हैं:
अचानक या अपवाद वाली स्थितियों को दिखाने के लिए, अपवाद बनाए और डाले जाते हैं.
किसी अपवाद के ज़रिए बताई गई समस्याओं को ठीक करने के लिए, प्रोग्राम को एक जानी-पहचानी स्थिति में वापस किया जाता है. इस प्रोसेस को अपवाद मैनेज करना कहा जाता है.
सबसे सही तरीका यह है कि सभी संभावित अपवादों को पकड़ना और मैनेज करना, जब तक कि प्रोग्राम को किसी अनजान स्थिति में न लौटाया जा सके.
यह कंट्रोल करने के लिए कि किस तरह के अपवादों को पकड़ना और किस कोड से हैंडल करना है, ऐसा कोड रैप करें जो try-catch ब्लॉक में अपवाद जनरेट कर सकता हो.
पक्का करें कि catch स्टेटमेंट में दी गई शर्तें उतनी ही छोटी हों जितनी किसी खास अपवादों के लिए सही तरीके से हैंडल की जा सकती हैं.
Unity या Crashlytics में अपवादों को लॉग करें
समस्या को डीबग करने के लिए, Unity या Crashlytics में
अपवाद रिकॉर्ड करने के कई तरीके हैं.
Crashlytics का इस्तेमाल करते समय, सबसे ज़्यादा इस्तेमाल किए जाने वाले और सुझाए गए
दो विकल्प यहां दिए गए हैं:
पहला विकल्प: Unity कंसोल में प्रिंट करें, लेकिन समस्या हल करने या डेवलपमेंट के दौरान
Crshlytics को रिपोर्ट न करें
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 में अपवाद को नुकसान पहुंचाने वाले इवेंट के तौर पर अपलोड करने के लिए.
अपवाद को लागू करने के लिए, इसे अनजान में अपवाद के तौर पर माना जाए और
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
//
}
