अपवाद आपका मित्र है

नब्बे के दशक के मध्य में, जब मैंने DOS के तहत प्रोग्रामिंग से विंडोज में स्विच किया, तो मेरे गुरु ने मुझे अपवाद तंत्र से परिचित कराया।
तब से, एक राय ने मेरे दिमाग में जड़ जमा ली है: एक प्रोग्राम जो अपवाद के साथ क्रैश होता है वह एक बुरा प्रोग्राम है। सभी अपवादों को संभाला जाना चाहिए और आपातकाल के मामले में आवेदन को समाप्त कर दिया जाना चाहिए।
और यह एक नियमित विंडोज एप्लिकेशन के लिए काफी सच है। दरअसल, एप्लिकेशन क्रैश होने की स्थिति में, उपयोगकर्ता को एक स्लैड एरर संदेश प्राप्त होता है और, परिणामस्वरूप, एक अप्राप्य एप्लिकेशन की नकारात्मक धारणा।
स्वचालित अपवाद हैंडलिंग टूल (जैसे यूरेकालॉग और इसके एनालॉग्स) के बारे में जानने के बाद मेरी राय बदलना शुरू हुई।
और आखिरकार Google Play रिपोर्टिंग सिस्टम के साथ मिलने के बाद बदल गया।
यह पोस्ट उन हजारों उदाहरणों के खिलाफ आत्मा का रोना है जो हमें हमारे कोड में दाने की जांच करना सिखाते हैं।

इस पोस्ट को लिखने का कारण एक दोस्त के साथ एक संवाद था, जिसने जावा कोड के साथ एनडीके की बातचीत को लागू करने के लिए सलाह मांगी थी। मुझे इस मैनुअल के आधार पर लिखा गया स्रोत कोड दिखाया गया था।
प्रश्न कोड:

jmethodID method = env->GetStaticMethodID(interfaceClass, "callBack", "(Ljava/lang/String;)V"); if(!method) { LOGE("callback_handler: failed to get method ID"); return; } env->CallStaticVoidMethod(interfaceClass, method, js); 

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

चेक केवल त्रुटि दिखाता है।

यह समझना बहुत महत्वपूर्ण है कि मास्किंग त्रुटियां खराब हैं। एक अपवाद के साथ एक आवेदन छोड़ने से भी बदतर।
आप कह सकते हैं कि परीक्षण के दौरान संदेश लॉग और पॉप अप है।
अच्छा है, अगर यह पॉप अप। और अगर यह ऊपर नहीं आता है? यदि कोई उपयोगकर्ता बेकार कोड छोड़ देता है, तो कौन चुपचाप कॉलबैक को अनदेखा करेगा?
आपके उपयोगकर्ता एक ऐसे प्रोग्राम के साथ काम करेंगे जो इच्छित कार्यक्षमता को पूरा नहीं करता है। खैर, अगर यह कुछ ट्रिफ़ल है जो गंभीरता से आवेदन को प्रभावित नहीं करता है। लेकिन क्या होगा अगर कोड का एक महत्वपूर्ण हिस्सा वहां छिपा हुआ है, जिसके कारण उपयोगकर्ता के काम के सभी परिणाम गलत हो जाते हैं?
चेक निकालें और पहला उपयोगकर्ता जो एक कॉलबैक कॉल का सामना करता है, उसे एप्लिकेशन क्रैश प्राप्त होगा। और आप - एक भरे हुए कॉल स्टैक के साथ एक त्रुटि रिपोर्ट। कम से कम, यह समस्या की ओर आपका ध्यान आकर्षित करेगा। हां, उपयोगकर्ता नाखुश होगा। लेकिन पांच घंटों में आप Google Play पर एक नया संस्करण अपलोड करेंगे और हजारों उपयोगकर्ताओं को इस समस्या के बारे में पता भी नहीं चलेगा।
यह टाइम बम एप्लिकेशन के साथ काम करने वाले विशाल ग्राहक आधार से बहुत बेहतर है।

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

तो चेक से क्या करना है?

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

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