व्यवस्थापक SDK त्रुटि प्रबंधन

व्यवस्थापक SDK त्रुटियों को दो श्रेणियों में विभाजित किया गया है:

  1. प्रोग्रामिंग त्रुटियाँ: ये उपयोगकर्ता एप्लिकेशन में प्रोग्रामिंग और कॉन्फ़िगरेशन त्रुटियाँ हैं। वे ज्यादातर एसडीके के गलत उपयोग के कारण होते हैं (जैसे कि एक विधि को null पास करना जो null मान स्वीकार नहीं करता है), और फायरबेस प्रोजेक्ट या एसडीके स्तर पर अन्य कॉन्फ़िगरेशन त्रुटियां (अनुपलब्ध क्रेडेंशियल, गलत प्रोजेक्ट आईडी स्ट्रिंग, और इसी तरह) पर)।
  2. एपीआई त्रुटियां: इनमें एसडीके कार्यान्वयन के भीतर होने वाली विभिन्न पुनर्प्राप्ति योग्य त्रुटियां, फायरबेस बैकएंड सेवाओं में उत्पन्न होने वाली सभी त्रुटियां, और अन्य क्षणिक त्रुटियां (जैसे टाइमआउट) शामिल हैं जो आरपीसी कॉल करते समय हो सकती हैं।

एडमिन एसडीके एक त्रुटि फेंककर प्रोग्रामिंग त्रुटियों का संकेत देता है जो संबंधित प्लेटफॉर्म से संबंधित है।

  • जावा: IllegalArgumentException , NullPointerException या समान अंतर्निहित रनटाइम त्रुटि प्रकार के उदाहरण फेंकता है।
  • पायथन: ValueError , TypeError या अन्य अंतर्निहित त्रुटि प्रकार के उदाहरण उठाता है।
  • जाओ: एक सामान्य त्रुटि लौटाता है।
  • .NET: ArgumentException , ArgumentNullException या समान अंतर्निहित त्रुटि प्रकार के उदाहरण फेंकता है।

अधिकांश स्थितियों में आपको प्रोग्रामिंग त्रुटियों को स्पष्ट रूप से नहीं संभालना चाहिए। इसके बजाय, आपको प्रोग्रामिंग त्रुटियों से पूरी तरह बचने के लिए अपना कोड और कॉन्फ़िगरेशन ठीक करना चाहिए। निम्नलिखित जावा स्निपेट पर विचार करें:

String uid = getUserInput();

UserRecord user = FirebaseAuth.getInstance().getUser(uid);

यदि getUserInput() विधि null या खाली स्ट्रिंग लौटाती है, FirebaseAuth.getUser() API एक IllegalArgumentException फेंकता है। इसे स्पष्ट रूप से संभालने के बजाय, आप यह सुनिश्चित करके समस्या को कम कर सकते हैं getUserInput() विधि कभी भी अमान्य यूआईडी स्ट्रिंग नहीं लौटाती है। यदि यह संभव नहीं है, तो अपने कोड में आवश्यक तर्क जाँच को निम्नानुसार कार्यान्वित करें:

String uid = getUserInput();
if (Strings.isNullOrEmpty(uid)) {
    log.warn("UID must not be null or empty");
    return;
}

UserRecord user = FirebaseAuth.getInstance().getUser(uid);

एक सिद्धांत के रूप में, प्रोग्रामिंग त्रुटियों पर कभी भी दोबारा प्रयास न करें। प्रोग्रामिंग त्रुटियों पर फ़ेल-फ़ास्ट सिमेंटिक्स की अनुमति देना अक्सर कार्रवाई का सबसे अच्छा तरीका होता है क्योंकि यह विकास के दौरान प्रोग्रामिंग बग और कॉन्फ़िगरेशन त्रुटियों को उजागर करता है, जहां उन्हें तुरंत ठीक किया जा सकता है। इस संदर्भ में फेल-फास्ट का अर्थ यह हो सकता है कि त्रुटियों को आपके एप्लिकेशन में वैश्विक त्रुटि हैंडलर तक फैलने दिया जाए, या केवल ऑडिट उद्देश्यों के लिए उन्हें लॉग किया जाए और उसके बाद वर्तमान निष्पादन प्रवाह को समाप्त किया जाए (एप्लिकेशन को क्रैश नहीं होना चाहिए)। सामान्य तौर पर, अपनी प्रोग्रामिंग भाषा और एप्लिकेशन फ्रेमवर्क की त्रुटि प्रबंधन की सर्वोत्तम प्रथाओं का पालन करें। त्रुटियों के इस वर्ग से सही ढंग से निपटने के लिए अक्सर यह अकेला ही पर्याप्त होता है।

आमतौर पर, आपके अधिकांश त्रुटि प्रबंधन प्रयास एपीआई त्रुटियों को संभालने पर केंद्रित होंगे। इनमें से कुछ त्रुटियाँ पुनर्प्राप्त करने योग्य हैं, जैसे अस्थायी रूप से अनुपलब्ध सेवा के परिणामस्वरूप उत्पन्न त्रुटियाँ, और कुछ सामान्य प्रोग्राम निष्पादन प्रवाह के दौरान भी प्रत्याशित होती हैं, जैसे अमान्य या समाप्त आईडी टोकन का पता लगाना। इस गाइड का बाकी हिस्सा बताता है कि एडमिन एसडीके ऐसी एपीआई त्रुटियों का प्रतिनिधित्व कैसे करता है, और उन्हें संभालने के लिए विभिन्न विकल्प उपलब्ध हैं।

एपीआई त्रुटि की संरचना

एक एपीआई त्रुटि में निम्नलिखित घटक होते हैं:

  1. त्रुटि कोड
  2. त्रुटि संदेश
  3. सेवा त्रुटि कोड (वैकल्पिक)
  4. HTTP प्रतिक्रिया (वैकल्पिक)

प्रत्येक एपीआई त्रुटि में एक त्रुटि कोड और एक त्रुटि संदेश होने की गारंटी होती है। कुछ एपीआई त्रुटियों में एक सेवा त्रुटि कोड भी होता है जो त्रुटि उत्पन्न करने वाले एपीआई के लिए विशिष्ट होता है। उदाहरण के लिए, फ़ायरबेस ऑथ एपीआई द्वारा उत्पन्न कुछ त्रुटियों में एक सेवा त्रुटि कोड होता है जो फ़ायरबेस ऑथ के लिए विशिष्ट होता है। यदि त्रुटि बैकएंड सेवा से HTTP त्रुटि प्रतिक्रिया का परिणाम थी, तो एपीआई त्रुटि में संबंधित HTTP प्रतिक्रिया भी शामिल होती है। इसका उपयोग मूल प्रतिक्रिया के सटीक हेडर और सामग्री का निरीक्षण करने के लिए किया जा सकता है, जो डिबगिंग, लॉगिंग या अधिक परिष्कृत त्रुटि प्रबंधन तर्क को लागू करने के लिए उपयोगी है।

Node.js को छोड़कर सभी एडमिन SDK कार्यान्वयन API प्रदान करते हैं जो API त्रुटियों के उपरोक्त घटकों तक पहुँचने में सक्षम बनाते हैं।

भाषा के अनुसार त्रुटि प्रकार और एपीआई

जावा

जावा में सभी API त्रुटियाँ FirebaseException क्लास का विस्तार करती हैं। आप इस बेस क्लास से त्रुटि कोड, त्रुटि संदेश और वैकल्पिक HTTP प्रतिक्रिया तक पहुंच सकते हैं।

public class FirebaseException extends Exception {
    @NonNull
    public ErrorCode getErrorCode() {
        // ...
    }

    @NonNull
    public String getMessage() {
        // ...
    }

    @Nullable
    public IncomingHttpResponse getHttpResponse() {
        // ...
    }
}

सेवा त्रुटि कोड को उजागर करने वाले एपीआई FirebaseException के एपीआई-विशिष्ट उपवर्ग प्रदान करते हैं। उदाहरण के लिए, FirebaseAuth API में सभी सार्वजनिक तरीकों को FirebaseAuthException के उदाहरणों को फेंकने के लिए घोषित किया गया है। आप इस व्युत्पन्न वर्ग से सेवा त्रुटि कोड तक पहुंच सकते हैं।

public class FirebaseAuthException extends FirebaseException {
    @Nullable
    public AuthErrorCode getAuthErrorCode() {
        // ...
    }
}

अजगर

पायथन में सभी एपीआई त्रुटियाँ अपवादों का विस्तार करती हैं exceptions.FirebaseError वर्ग। आप इस बेस क्लास से त्रुटि कोड, त्रुटि संदेश और वैकल्पिक HTTP प्रतिक्रिया तक पहुंच सकते हैं।

class FirebaseError(Exception):
    @property
    def code(self):
          # ...

    @property
    def message(self):
          # ...

    @property
    def http_response(self):
          # ...

इसके अलावा, पायथन एडमिन एसडीके प्रत्येक त्रुटि कोड के लिए अलग-अलग व्युत्पन्न कक्षाएं प्रदान करता है। हम उन्हें प्लेटफ़ॉर्म त्रुटि वर्ग के रूप में संदर्भित करते हैं।

class InvalidArgumentError(FirebaseError):
    # ...

class NotFoundError(FirebaseError):
    # ...

आप या तो अपने कोड में FirebaseError पकड़ सकते हैं और उसके code जांच कर सकते हैं, या प्लेटफ़ॉर्म त्रुटि वर्ग के विरुद्ध isinstance() जांच कर सकते हैं। या आप विशिष्ट प्लेटफ़ॉर्म त्रुटि प्रकारों को सीधे पकड़ने के लिए कोड लिख सकते हैं। बाद वाले दृष्टिकोण के परिणामस्वरूप अधिक पठनीय त्रुटि प्रबंधन कोड प्राप्त होने की संभावना है।

सेवा त्रुटि कोड को उजागर करने वाले एपीआई प्लेटफ़ॉर्म त्रुटि वर्गों के एपीआई-विशिष्ट उपवर्ग प्रदान करते हैं। उदाहरण के लिए, auth मॉड्यूल में सभी सार्वजनिक विधियाँ API-विशिष्ट त्रुटि प्रकार जैसे auth.UserNotFoundError और auth.ExpiredIdTokenError उत्पन्न कर सकती हैं।

class UserNotFoundError(exceptions.NotFoundError):
    # …

class ExpiredIdTokenError(exceptions.InvalidArgumentError):
    # ...

जाना

गो एडमिन एसडीके एक errorutils पैकेज प्रदान करता है जिसमें फ़ंक्शंस की एक श्रृंखला होती है जो त्रुटि कोड के परीक्षण की अनुमति देती है।

package errorutils

func IsInvalidArgument(err error) bool {
    // ...
}

func IsNotFound(err error) bool {
    // ...
}

त्रुटि संदेश केवल त्रुटि के Error() फ़ंक्शन द्वारा लौटाई गई स्ट्रिंग है। वैकल्पिक HTTP प्रतिक्रिया को errorutils.HTTPResponse() फ़ंक्शन को कॉल करके एक्सेस किया जा सकता है, जो *http.Response लौटाता है।

errorutils पैकेज में त्रुटि जाँच कार्यों के लिए nil या कोई अन्य त्रुटि मान पास करना सुरक्षित है। यदि इनपुट तर्क में वास्तव में प्रश्न में त्रुटि कोड शामिल है, तो वे true लौटाते हैं, और बाकी सभी चीजों के लिए false लौटाते हैं। HTTPResponse() फ़ंक्शन का व्यवहार समान है, सिवाय इसके कि यह false के बजाय nil लौटाता है।

एपीआई जो सेवा त्रुटि कोड को उजागर करते हैं, संबंधित पैकेजों में एपीआई-विशिष्ट त्रुटि जांच फ़ंक्शन प्रदान करते हैं। उदाहरण के लिए, auth पैकेज IsUserNotFound() और IsExpiredIDTokenError() फ़ंक्शन प्रदान करता है।

।जाल

.NET में सभी API त्रुटियाँ FirebaseException क्लास का विस्तार करती हैं। आप इस बेस क्लास से प्लेटफ़ॉर्म त्रुटि कोड, त्रुटि संदेश और वैकल्पिक HTTP प्रतिक्रिया तक पहुंच सकते हैं।

public class FirebaseException : Exception {

    public ErrorCode ErrorCode { get; }

    public String Message { get; }

    public HttpResponseMessage HttpResponse { get; }
}

सेवा त्रुटि कोड को उजागर करने वाले एपीआई FirebaseException के एपीआई-विशिष्ट उपवर्ग प्रदान करते हैं। उदाहरण के लिए, FirebaseAuth API में सभी सार्वजनिक तरीकों को FirebaseAuthException के उदाहरणों को फेंकने के लिए घोषित किया गया है। आप इस व्युत्पन्न वर्ग से सेवा त्रुटि कोड तक पहुंच सकते हैं।

public class FirebaseAuthException : FirebaseException {

    public AuthErrorCode AuthErrorCode { get; }
}

प्लेटफ़ॉर्म त्रुटि कोड

त्रुटि कोड सभी फायरबेस और Google क्लाउड प्लेटफ़ॉर्म सेवाओं में आम हैं। निम्न तालिका सभी संभावित प्लेटफ़ॉर्म त्रुटि कोड की रूपरेखा प्रस्तुत करती है। यह एक स्थिर सूची है और इसके लंबी अवधि तक अपरिवर्तित रहने की उम्मीद है।

अमान्य दलील क्लाइंट ने एक अमान्य तर्क निर्दिष्ट किया.
FAILED_पूर्व शर्त वर्तमान सिस्टम स्थिति में अनुरोध निष्पादित नहीं किया जा सकता है, जैसे गैर-रिक्त निर्देशिका को हटाना।
सीमा से बाहर क्लाइंट ने एक अमान्य श्रेणी निर्दिष्ट की.
अपुष्ट गुम, अमान्य या समाप्त OAuth टोकन के कारण अनुरोध प्रमाणित नहीं हुआ।
अनुमति नहीं मिली क्लाइंट के पास पर्याप्त अनुमति नहीं है. ऐसा इसलिए हो सकता है क्योंकि OAuth टोकन में सही स्कोप नहीं है, क्लाइंट के पास अनुमति नहीं है, या क्लाइंट प्रोजेक्ट के लिए API सक्षम नहीं किया गया है।
नहीं मिला निर्दिष्ट संसाधन नहीं मिला, या श्वेतसूची जैसे अज्ञात कारणों से अनुरोध अस्वीकार कर दिया गया है।
टकराव समवर्ती संघर्ष, जैसे पढ़ने-संशोधित-लिखने का संघर्ष। केवल कुछ विरासती सेवाओं द्वारा उपयोग किया जाता है। अधिकांश सेवाएँ इसके बजाय ABORTED या ALREADY_EXISTS का उपयोग करती हैं। यह देखने के लिए कि आपके कोड में किसे संभालना है, सेवा-विशिष्ट दस्तावेज़ देखें।
निरस्त किया गया समवर्ती संघर्ष, जैसे पढ़ने-संशोधित-लिखने का संघर्ष।
पहले से ही मौजूद है क्लाइंट ने जिस संसाधन को बनाने का प्रयास किया वह पहले से मौजूद है।
संसाधन_खत्म या तो संसाधन कोटा से बाहर या सीमित दर तक पहुँच रहा है।
रद्द ग्राहक द्वारा अनुरोध रद्द कर दिया गया.
डेटा हानि अप्राप्य डेटा हानि या डेटा भ्रष्टाचार। क्लाइंट को उपयोगकर्ता को त्रुटि की रिपोर्ट करनी चाहिए।
अज्ञात अज्ञात सर्वर त्रुटि. आमतौर पर एक सर्वर बग.

यह त्रुटि कोड स्थानीय प्रतिक्रिया पार्सिंग (अनमार्शल) त्रुटियों और अन्य निम्न-स्तरीय I/O त्रुटियों की एक विस्तृत श्रृंखला को भी सौंपा गया है जिनका आसानी से निदान नहीं किया जा सकता है।

आंतरिक आंतरिक सर्वर त्रुटि। आमतौर पर एक सर्वर बग.
अनुपलब्ध सेवा अनुपलब्ध है। आमतौर पर सर्वर अस्थायी रूप से डाउन होता है।

यह त्रुटि कोड स्थानीय नेटवर्क त्रुटियों (कनेक्शन अस्वीकृत, होस्ट करने के लिए कोई मार्ग नहीं) को भी सौंपा गया है।

DEADLINE_EXCEEDED अनुरोध की समय सीमा पार हो गई. यह केवल तभी होगा जब कॉल करने वाला एक समय सीमा निर्धारित करता है जो लक्ष्य एपीआई की डिफ़ॉल्ट समय सीमा से कम है (यानी अनुरोधित समय सीमा सर्वर के लिए अनुरोध को संसाधित करने के लिए पर्याप्त नहीं है), और अनुरोध समय सीमा के भीतर समाप्त नहीं हुआ है।

यह त्रुटि कोड स्थानीय कनेक्शन और रीड टाइमआउट को भी सौंपा गया है।

अधिकांश एपीआई के परिणामस्वरूप केवल उपरोक्त त्रुटि कोड का एक उपसमूह हो सकता है। किसी भी स्थिति में, आपसे अपने त्रुटि हैंडलर को लागू करते समय इन सभी त्रुटि कोडों को स्पष्ट रूप से संभालने की अपेक्षा नहीं की जाती है। अधिकांश एप्लिकेशन केवल 1-2 विशिष्ट त्रुटि कोड में रुचि लेंगे और बाकी सभी को एक सामान्य, अप्राप्य विफलता के रूप में मानेंगे।

सेवा-विशिष्ट त्रुटि कोड

फायरबेस प्रामाणिक

प्रमाणपत्र_FETCH_असफल JWT (आईडी टोकन या सत्र कुकी) को सत्यापित करने के लिए आवश्यक सार्वजनिक कुंजी प्रमाणपत्र लाने में विफल।
ईमेल पहले से ही मौजूद है प्रदत्त ईमेल के साथ एक उपयोगकर्ता पहले से मौजूद है।
EXPIRED_ID_TOKEN verifyIdToken() के लिए निर्दिष्ट आईडी टोकन समाप्त हो गया है।
EXPIRED_SESSION_COOKIE verifySessionCookie() II के लिए निर्दिष्ट सत्र कुकी समाप्त हो गई है।
INVALID_DYNAMIC_LINK_DOMAIN प्रदत्त डायनामिक लिंक डोमेन वर्तमान प्रोजेक्ट के लिए कॉन्फ़िगर या अधिकृत नहीं है। ईमेल एक्शन लिंक एपीआई से संबंधित।
INVALID_ID_TOKEN verifyIdToken() के लिए निर्दिष्ट आईडी टोकन अमान्य है।
INVALID_SESSION_COOKIE verifySessionCookie() के लिए निर्दिष्ट सत्र कुकी अमान्य है।
PHONE_NUMBER_ALREADY_EXISTS प्रदत्त फ़ोन नंबर के साथ एक उपयोगकर्ता पहले से मौजूद है।
निरस्त_आईडी_टोकन verifyIdToken() के लिए निर्दिष्ट आईडी टोकन निरस्त कर दिया गया है।
निरस्त_सत्र_कुकी verifySessionCookie() के लिए निर्दिष्ट सत्र कुकी समाप्त हो गई है।
अनधिकृत_CONTINUE_URL जारी यूआरएल का डोमेन श्वेतसूची में नहीं है। ईमेल एक्शन लिंक एपीआई से संबंधित।
उपयोगकर्ता नहीं मिला दिए गए पहचानकर्ता के लिए कोई उपयोगकर्ता रिकॉर्ड नहीं मिला।

फायरबेस क्लाउड मैसेजिंग

तृतीय_पक्ष_प्रामाणिक_त्रुटि एपीएन प्रमाणपत्र या वेब पुश ऑथ एपीआई कुंजी अमान्य या अनुपलब्ध थी।
अमान्य दलील अनुरोध में निर्दिष्ट एक या अधिक तर्क अमान्य थे।
आंतरिक आंतरिक सर्वर त्रुटि।
कोटा पूरा हो गया संदेश लक्ष्य के लिए भेजने की सीमा पार हो गई.
SENDER_ID_MISMATCH प्रमाणित प्रेषक आईडी पंजीकरण टोकन के लिए प्रेषक आईडी से भिन्न है। इसका आम तौर पर मतलब यह है कि प्रेषक और लक्ष्य पंजीकरण टोकन एक ही फायरबेस प्रोजेक्ट में नहीं हैं।
अनुपलब्ध क्लाउड मैसेजिंग सेवा अस्थायी रूप से अनुपलब्ध है.
अपंजीकृत ऐप इंस्टेंस FCM से अपंजीकृत था। इसका आमतौर पर मतलब यह है कि उपयोग किया गया डिवाइस पंजीकरण टोकन अब वैध नहीं है और एक नया उपयोग किया जाना चाहिए।

स्वचालित पुनः प्रयास

व्यवस्थापक SDK उन त्रुटियों को उपयोगकर्ताओं के सामने उजागर करने से पहले स्वचालित रूप से कुछ त्रुटियों का पुनः प्रयास करता है। सामान्य तौर पर, निम्नलिखित प्रकार की त्रुटियों का पारदर्शी रूप से पुनः प्रयास किया जाता है:

  • HTTP 503 (सेवा अनुपलब्ध) प्रतिक्रियाओं के परिणामस्वरूप सभी एपीआई त्रुटियां।
  • HTTP 500 (आंतरिक सर्वर त्रुटि) प्रतिक्रियाओं के परिणामस्वरूप कुछ एपीआई त्रुटियाँ।
  • अधिकांश निम्न-स्तरीय I/O त्रुटियाँ (कनेक्शन अस्वीकृत, कनेक्शन रीसेट आदि)।

एसडीके उपरोक्त त्रुटियों में से प्रत्येक को घातीय बैकऑफ़ के साथ 5 बार (मूल प्रयास + 4 पुनः प्रयास) तक पुनः प्रयास करेगा। यदि आप चाहें तो आप एप्लिकेशन स्तर पर अपने स्वयं के पुनः प्रयास तंत्र को कार्यान्वित कर सकते हैं, लेकिन आमतौर पर इसकी आवश्यकता नहीं होती है।

पुन: प्रयास करें-समर्थन के बाद

एडमिन एसडीके का गो और .NET कार्यान्वयन HTTP Retry-After हेडर को संभालने के लिए समर्थन के साथ आता है। अर्थात्, यदि बैकएंड सर्वर द्वारा भेजी गई त्रुटि प्रतिक्रिया में मानक Retry-After हेडर शामिल है, तो एसडीके इसका सम्मान करेगा जब पुनः प्रयास करते समय निर्दिष्ट प्रतीक्षा अवधि बहुत लंबी न हो। यदि Retry-After हेडर बहुत लंबी प्रतीक्षा अवधि को इंगित करता है, तो एसडीके रिट्रीट को बायपास कर देगा और उचित एपीआई त्रुटि फेंक देगा।

पायथन एडमिन एसडीके वर्तमान में Retry-After हेडर का समर्थन नहीं करता है, और केवल सरल घातीय बैकऑफ़ का समर्थन करता है।

एपीआई त्रुटि प्रबंधन उदाहरण

एक सामान्य त्रुटि हैंडलर लागू करना

ज्यादातर मामलों में आप जो चाहते हैं वह एक सामान्य त्रुटि हैंडलर है जो एपीआई त्रुटि के कारण प्रोग्राम प्रवाह की अप्रत्याशित समाप्ति को रोकने के लिए त्रुटियों की एक विस्तृत श्रृंखला को पकड़ता है। ऐसे त्रुटि हैंडलर आमतौर पर केवल ऑडिट उद्देश्यों के लिए त्रुटियों को लॉग करते हैं, या सभी सामने आई एपीआई त्रुटियों के लिए कुछ अन्य डिफ़ॉल्ट त्रुटि प्रबंधन रूटीन को लागू करते हैं। जरूरी नहीं कि वे अलग-अलग त्रुटि कोड या उन कारणों में रुचि रखते हों जिनके कारण त्रुटि हुई हो।

जावा

try {
  FirebaseToken token = FirebaseAuth.getInstance().verifyIdToken(idToken);
  performPrivilegedOperation(token.getUid());
} catch (FirebaseAuthException ex) {
  System.err.println("Failed to verify ID token: " + ex.getMessage());
}

अजगर

try:
  token = auth.verify_id_token(idToken)
  perform_privileged_pperation(token.uid)
except exceptions.FirebaseError as ex:
  print(f'Failed to verify ID token: {ex}')

जाना

token, err := client.VerifyIDToken(ctx, idToken)
if err != nil {
  log.Printf("Failed to verify ID token: %v", err)
  return
}

performPrivilegedOperation(token)

।जाल

try
{
  var token = await FirebaseAuth.DefaultInstance.VerifyIdTokenAsync(idToken);
  PerformPrivilegedOperation(token.getUid());
}
catch (FirebaseAuthException ex) 
{
  Conole.WriteLine($"Failed to verify ID token: {ex.Message}");
}

त्रुटि कोड की जाँच करना

कुछ मामलों में, आप सटीक त्रुटि कोड का निरीक्षण करना चाहेंगे, और विभिन्न संदर्भ-जागरूक त्रुटि प्रबंधन रूटीन को लागू करना चाहेंगे। निम्नलिखित उदाहरण में, हमारे पास एक त्रुटि हैंडलर है जो सेवा त्रुटि कोड के आधार पर अधिक विशिष्ट त्रुटि संदेशों को लॉग करता है।

जावा

try {
  FirebaseToken token = FirebaseAuth.getInstance().verifyIdToken(idToken);
  performPrivilegedOperation(token.getUid());
} catch (FirebaseAuthException ex) {
  if (ex.getAuthErrorCode() == AuthErrorCode.ID_TOKEN_EXPIRED) {
    System.err.println("ID token has expired");
  } else if (ex.getAuthErrorCode() == AuthErrorCode.ID_TOKEN_INVALID) {
    System.err.println("ID token is malformed or invalid");
  } else {
    System.err.println("Failed to verify ID token: " + ex.getMessage());
  }
}

अजगर

try:
  token = auth.verify_id_token(idToken)
  perform_privileged_operation(token.uid)
except auth.ExpiredIdTokenError:
  print('ID token has expired')
except auth.InvalidIdTokenError:
  print('ID token is malformed or invalid')
except exceptions.FirebaseError as ex:
  print(f'Failed to verify ID token: {ex}')

जाना

token, err := client.VerifyIDToken(ctx, idToken)
if auth.IsIDTokenExpired(err) {
  log.Print("ID token has expired")
  return
}
if auth.IsIDTokenInvalid(err) {
  log.Print("ID token is malformed or invalid")
  return
}
if err != nil {
  log.Printf("Failed to verify ID token: %v", err)
  return
}

performPrivilegedOperation(token)

।जाल

try
{
  var token = await FirebaseAuth.DefaultInstance.VerifyIdTokenAsync(idToken);
  PerformPrivilegedOperation(token.getUid());
}
catch (FirebaseAuthException ex)
{
  if (ex.AuthErrorCode == AuthErrorCode.ExpiredIdToken)
  {
    Console.WriteLine("ID token has expired");
  }
  else if (ex.AuthErrorCode == AuthErrorCode.InvalidIdToken)
  {
    Console.WriteLine("ID token is malformed or invalid");
  }
  else
  {
    Conole.WriteLine($"Failed to verify ID token: {ex.Message}");
  }
}

यहां एक और उदाहरण है जहां हम शीर्ष-स्तरीय और सेवा त्रुटि कोड दोनों की जांच करते हैं:

जावा

try {
  FirebaseMessaging.getInstance().send(createMyMessage());
} catch (FirebaseMessagingException ex){
  if (ex.getMessagingErrorCode() == MessagingErrorCode.UNREGISTERED) {
    System.err.println("App instance has been unregistered");
    removeTokenFromDatabase();
  } else if (ex.getErrorCode() == ErrorCode.Unavailable) {
    System.err.println("FCM service is temporarily unavailable");
    scheduleForRetryInAnHour();
  } else {
    System.err.println("Failed to send notification: " + ex.getMessage());
  }
}

अजगर

try:
  messaging.send(create_my_message())
except messaging.UnregisteredError:
  print('App instance has been unregistered')
  remove_token_from_database()
except exceptions.UnavailableError:
  print('FCM service is temporarily unavailable')
  schedule_for_retry_in_an_hour()
except exceptions.FirebaseError as ex:
  print(f'Failed to send notification: {ex}')

जाना

_, err := client.Send(ctx, createMyMessage())
if messaging.IsUnregistered(err) {
  log.Print("App instance has been unregistered")
  removeTokenFromDatabase()
  return
}
if errorutils.IsUnavailable(err) {
  log.Print("FCM service is temporarily unavailable")
  scheduleForRetryInAnHour()
  return
}
if err != nil {
  log.Printf("Failed to send notification: %v", err)
  return
}

।जाल

try
{
  await FirebaseMessaging.DefaultInstance.SendAsync(createMyMessage());
}
catch (FirebaseMessagingException ex)
{
  if (ex.MessagingErrorCode == MessagingErrorCode.UNREGISTERED)
  {
    Console.WriteLine("App instance has been unregistered");
    removeTokenFromDatabase();
  }
  else if (ex.ErrorCode == ErrorCode.Unavailable)
  {
    Console.WriteLine("FCM service is temporarily unavailable");
    scheduleForRetryInAnHour();
  }
  else
  {
    Console.WriteLine($"Failed to send notification: {ex.Message}");
  }
}

HTTP प्रतिक्रिया तक पहुँचना

कुछ दुर्लभ मामलों में आप बैकएंड सेवा द्वारा लौटाए गए HTTP त्रुटि प्रतिक्रिया का निरीक्षण करना और उस पर कुछ त्रुटि प्रबंधन कार्रवाई करना चाह सकते हैं। एडमिन एसडीके इन त्रुटि प्रतिक्रियाओं के हेडर और सामग्री दोनों को उजागर करता है। प्रतिक्रिया सामग्री आमतौर पर एक स्ट्रिंग या कच्चे बाइट अनुक्रम के रूप में लौटाई जाती है, और इसे किसी भी आवश्यक लक्ष्य प्रारूप में पार्स किया जा सकता है।

जावा

try {
  FirebaseMessaging.getInstance().send(createMyMessage());
} catch (FirebaseMessagingException ex){
  IncomingHttpResponse response = ex.getHttpResponse();
  if (response != null) {
    System.err.println("FCM service responded with HTTP " + response.getStatusCode());

    Map<String, Object> headers = response.getHeaders();
    for (Map.Entry<String, Object> entry : headers.entrySet()) {
      System.err.println(">>> " + entry.getKey() + ": " + entry.getValue());
    }

    System.err.println(">>>");
    System.err.println(">>> " + response.getContent());
  }
}

अजगर

try:
  messaging.send(create_my_message())
except exceptions.FirebaseError as ex:
  response = ex.http_response
  if response is not None:
    print(f'FCM service responded with HTTP {response.status_code}')

    for key, value in response.headers.items():
      print(f'>>> {key}: {value}')

    print('>>>')
    print(f'>>> {response.content}')

जाना

_, err := client.Send(ctx, createMyMessage())
if resp := errorutils.HTTPResponse(err); resp != nil {
  log.Printf("FCM service responded with HTTP %d", resp.StatusCode)

  for key, value := range resp.Header {
      log.Printf(">>> %s: %v", key, value)
  }

  defer resp.Body.Close()
  b, _ := ioutil.ReadAll(resp.Body)
  log.Print(">>>")
  log.Printf(">>> %s", string(b))

  return
}

।जाल

try
{
  await FirebaseMessaging.DefaultInstance.SendAsync(createMyMessage());
}
catch (FirebaseMessagingException ex)
{
  var response = ex.HttpResponse
  if response != null
  {
    Console.WriteLine($"FCM service responded with HTTP { response.StatusCode}");

    var headers = response.Headers;
    for (var entry in response.Headers)
    {
      Console.WriteLine($">>> {entry.Key}: {entry.Value}");
    }

    var body = await response.Content.ReadAsString();
    Console.WriteLine(">>>");
    Console.WriteLine($">>> {body}");
  }
}