Kotlin में चेक किए गए अपवादों का इस्तेमाल नहीं किया जा सकता. इससे त्रुटि प्रबंधन सरल और सुव्यवस्थित हो जाता है, क्योंकि आप केवल उन्हीं अपवादों को संभालने का विकल्प चुन सकते हैं जो संभावित रूप से सुधारे जा सकते हैं. साथ ही, आपको हर संभावित अपवाद को साफ़ तौर पर हैंडल करने की ज़रूरत नहीं होती. इसलिए, आपका कोड कम उलझा हुआ होता है और इस वजह से, अपने मुख्य मकसद पर ज़्यादा फ़ोकस करता है.
ऐसी गड़बड़ियां जिन्हें डेवलपर अपने लेवल पर ठीक कर सकता है.
उदाहरण के लिए, अगर कॉल में इस्तेमाल किया गया आईडी मान्य नहीं है, तो एपीआई invalid data मैसेज के साथ HomeException दिखाता है. इसके बाद, ऐप्लिकेशन डेवलपर के पास यह विकल्प होता है कि वह उस आईडी को अपनी कैश मेमोरी से हटा दे या उपयोगकर्ता को "स्ट्रक्चर नहीं मिला" जैसा मैसेज दिखाए.
गड़बड़ी को ठीक करने का एक उदाहरण:
val result =
try {
homeManager.requestPermissions()
} catch (e: HomeException) {
PermissionsResult(
PermissionsResultStatus.ERROR,
"Got HomeException with error: ${e.message}",
)
}
होम एपीआई में मौजूद कोई भी तरीका,
HomeException को थ्रो कर सकता है. इसलिए, हमारा सुझाव है कि सभी कॉल पर HomeException को पकड़ने के लिए, try-catch ब्लॉक का इस्तेमाल करें.
HomeException को मैनेज करते समय, उसके
error.code और
error.message फ़ील्ड देखें. इससे आपको गड़बड़ी के बारे में पता चलेगा. इसमें सब-गड़बड़ी कोड भी हो सकते हैं. इसलिए,
getSubErrorCodes() तरीके को कॉल करें और नतीजे देखें.
अगर किसी अपवाद को हैंडल नहीं किया जाता है, तो आपका ऐप्लिकेशन क्रैश हो जाएगा.
इस टेबल में, HomeException कोड के मतलब दिए गए हैं. ये कोड आपको दिख सकते हैं:
| कोड | मतलब |
|---|---|
ABORTED |
कार्रवाई को रद्द कर दिया गया है. आम तौर पर, ऐसा एक साथ कई अनुरोध मिलने की वजह से होता है. जैसे, सीक्वेंसर की जांच पूरी न हो पाना या लेन-देन रद्द हो जाना. |
ALREADY_EXISTS |
क्लाइंट ने जिस इकाई को बनाने की कोशिश की है वह पहले से मौजूद है. उदाहरण के लिए, कोई फ़ाइल या डायरेक्ट्री. |
API_NOT_CONNECTED |
क्लाइंट ने किसी ऐसे एपीआई से कोई तरीका कॉल करने की कोशिश की जो कनेक्ट नहीं हो सका. ऐसा तब हो सकता है, जब डिवाइस ऑफ़लाइन हो या क्लाइंट ने जिस एपीआई को कॉल करने की कोशिश की है वह काम न करता हो. |
CANCELLED |
कार्रवाई रद्द कर दी गई थी. आम तौर पर, ऐसा कॉल करने वाला व्यक्ति करता है. |
COMMAND_FAILED |
आदेश निष्पादित करने में विफल रहा. ज़्यादा जानकारी के लिए, सब गड़बड़ी कोड देखें. |
CURSOR_WINDOW_NOT_SUPPORTED |
एक ऐसे तरीके को कॉल किया गया है जो CursorWindow का इस्तेमाल करता है. हालांकि, CursorWindow या तो चालू नहीं है या मौजूदा कॉन्टेक्स्ट में काम नहीं करता. |
DATA_LOSS |
डेटा को वापस नहीं पाया जा सकता या डेटा खराब हो गया है. |
DEADLINE_EXCEEDED |
कार्रवाई पूरी होने से पहले ही समयसीमा खत्म हो गई. सिस्टम की स्थिति में बदलाव करने वाली कार्रवाइयों के लिए, यह गड़बड़ी तब भी दिख सकती है, जब कार्रवाई पूरी हो गई हो. |
DECOMMISSIONING_INELIGIBLE |
डिवाइस को बंद नहीं किया जा सका, क्योंकि यह डिवाइस बंद करने की ज़रूरी शर्तें पूरी नहीं करता. |
FAILED_PRECONDITION |
इस कार्रवाई को अस्वीकार कर दिया गया है, क्योंकि सिस्टम उस स्थिति में नहीं है जिसमें कार्रवाई को पूरा किया जा सकता है. उदाहरण के लिए, अगर आपने पहले से बंद ओवन पर stop कमांड का इस्तेमाल किया है, तो आपको यह मैसेज मिल सकता है.OvenCavityOperationalStateTrait |
INTERNAL |
सिस्टम की गड़बड़ियां. इसका मतलब है कि सिस्टम के कुछ इनवेरिएंट टूट गए हैं. यह गड़बड़ी कोड, गंभीर गड़बड़ियों के लिए रिज़र्व किया गया है. |
INVALID_ARGUMENT |
क्लाइंट ने एक ऐसा तर्क दिया है जो वैल्यू की अनुमानित सीमा से बाहर है. |
INVALID_DATA_HOLDER |
डेटा होल्डर अमान्य है. |
NOT_FOUND |
अनुरोध की गई इकाई, जैसे कि फ़ाइल या डायरेक्ट्री नहीं मिली.
अगर किसी अनुरोध को उपयोगकर्ताओं के पूरे ग्रुप के लिए अस्वीकार कर दिया जाता है, जैसे कि सुविधा को धीरे-धीरे रोल आउट करना या बिना दस्तावेज़ वाली अनुमति वाली सूची, तो NOT_FOUND का इस्तेमाल किया जा सकता है.
अगर उपयोगकर्ताओं के किसी ग्रुप के लिए अनुरोध अस्वीकार कर दिया जाता है, तो उपयोगकर्ता के आधार पर ऐक्सेस कंट्रोल जैसी सुविधा के लिए, PERMISSION_DENIED का इस्तेमाल करना ज़रूरी है. |
OUT_OF_RANGE |
कार्रवाई, मान्य सीमा के बाद की गई थी. जैसे, end-of-file के बाद खोजना या पढ़ना. INVALID_ARGUMENT के उलट, इस गड़बड़ी से पता चलता है कि सिस्टम की स्थिति बदलने पर समस्या ठीक हो सकती है. |
PERMISSION_DENIED |
कॉलर के पास, तय की गई कार्रवाई को पूरा करने की अनुमति नहीं है. PERMISSION_DENIED का इस्तेमाल, किसी संसाधन के खत्म होने की वजह से अस्वीकार किए गए अनुरोधों के लिए नहीं किया जाना चाहिए. ऐसी गड़बड़ियों के लिए RESOURCE_EXHAUSTED का इस्तेमाल करें.
अगर कॉल करने वाले की पहचान नहीं की जा सकती, तो PERMISSION_DENIED का इस्तेमाल नहीं किया जाना चाहिए. ऐसी गड़बड़ियों के लिए, UNAUTHENTICATED का इस्तेमाल करें.
इस गड़बड़ी के कोड का मतलब यह नहीं है कि अनुरोध मान्य है या अनुरोध की गई इकाई मौजूद है या अन्य ज़रूरी शर्तें पूरी करती है. |
RESOURCE_EXHAUSTED |
कुछ रिसॉर्स खत्म हो गए हैं. ऐसा शायद किसी उपयोगकर्ता के लिए तय किए गए कोटे के पूरा होने या पूरे फ़ाइल सिस्टम में जगह खत्म होने की वजह से हुआ है.
उदाहरण के लिए, यह गड़बड़ी तब हो सकती है, जब पालतू जानवरों को खाना देने वाले डिवाइस पर DispenseTrait की dispense कमांड को कॉल किया गया हो, लेकिन यूनिट में खाना न बचा हो. |
SDK_INITIALIZATION_MISSING_INFO |
एसडीके को सभी ज़रूरी जानकारी के बिना शुरू किया गया था.
उदाहरण के लिए, यह गड़बड़ी तब होती है, जब क्लाइंट किसी दिए गए ट्रेट आईडी के लिए TraitFactory पाने की कोशिश करता है, लेकिन SDK को शुरू करते समय ट्रेट को शामिल नहीं किया गया था. Android पर होम को शुरू करना लेख पढ़ें. |
UNAUTHENTICATED |
कॉल करने वाले की पहचान नहीं की जा सकती या अनुरोध में वैध प्रमाणीकरण क्रेडेंशियल नहीं हैं. |
UNAVAILABLE |
यह सेवा उपलब्ध नहीं है. यह एक अस्थायी समस्या है. कुछ समय बाद फिर से कोशिश करने पर, यह ठीक हो सकती है. ध्यान दें कि गैर-आईडम्पोटेंट कार्रवाइयों को फिर से आज़माना हमेशा सुरक्षित नहीं होता. |
UNIMPLEMENTED |
अनुरोध की गई कार्रवाई, इस सेवा में लागू नहीं की गई है, काम नहीं करती है या चालू नहीं है. |
UNKNOWN |
ऐसी गड़बड़ी जिसकी कोई जानकारी नहीं है. UNKNOWN तब दिखता है, जब कोई ऐसी गड़बड़ी होती है जिसे किसी अन्य गड़बड़ी कोड का इस्तेमाल करके कैटगरी में नहीं रखा जा सकता.
उदाहरण के लिए, यह गड़बड़ी तब दिख सकती है, जब किसी बाहरी एपीआई से मिली स्थिति की वैल्यू में, गड़बड़ी की वजह के बारे में ज़रूरी जानकारी न हो. |
WRITE_FAILED |
लिखने की प्रोसेस पूरी नहीं हो सकी. ज़्यादा जानकारी के लिए, सब गड़बड़ी कोड देखें. |