अपवादों को बचाया जा रहा है
<पी> रूबी में अपवादों को बचाकर आप अपने एप्लिकेशन को कुछ गलत होने पर क्रैश होने से रोक सकते हैं।begin .. rescue के साथ ब्लॉक करें, कोई त्रुटि होने पर आप अपने एप्लिकेशन के लिए एक वैकल्पिक पथ निर्दिष्ट कर सकते हैं। <पी> यह निर्दिष्ट करना भी संभव है कि किन अपवादों को बचाया जाना चाहिए। अपवाद वर्ग निर्दिष्ट करते समय, इस अपवाद के सभी उपवर्ग भी कैप्चर किए जाएंगे। <पी> उपरोक्त उदाहरण में आप अपवाद Errno::ENOENT देख सकते हैं तब पकड़ा जाता है जब उसका मूल SystemCallError होता है बचाया जा रहा है. अपवाद श्रृंखला में बहुत ऊपर बचाव
<पी> यह महत्वपूर्ण है कि अपवादों को अपवाद शृंखला से बहुत ऊपर न बचाया जाए। जब आप ऐसा करते हैं, तो सभी उपवर्गीकृत अपवाद भी पकड़े जाएंगे, जिससे बचाव ब्लॉक का कैप्चर बहुत सामान्य हो जाएगा। <पी> यहां एक प्रोग्राम है जो प्रोग्राम को दिए गए तर्क के आधार पर एक कॉन्फिग फ़ाइल को पढ़ता है। <पी> त्रुटि संदेश कहता है कि यह कॉन्फ़िगरेशन फ़ाइल को नहीं पढ़ सका, लेकिन वास्तविक समस्या कोड में टाइपो की त्रुटि थी। <पी> डिफ़ॉल्ट अपवाद वर्ग कोbegin .. rescue द्वारा पकड़ा गया ब्लॉक मानक त्रुटि है. यदि हम किसी विशिष्ट कक्षा में उत्तीर्ण नहीं होते हैं, तो रूबी मानक त्रुटि और सभी उपवर्ग त्रुटियों से बचाव करेगी। NoMethodError इन त्रुटियों में से एक है। <पी> एक विशिष्ट अपवाद वर्ग को बचाने से असंबद्ध त्रुटियों को गलती से विफलता की स्थिति उत्पन्न होने से रोकने में मदद मिलेगी। यह अधिक विशिष्ट कस्टम त्रुटि संदेशों की भी अनुमति देता है जो अंतिम उपयोगकर्ता के लिए अधिक उपयोगी होते हैं। बचाव अपवाद
<पी> अपवाद श्रृंखला में ऊपर बचाव करना अभी भी आकर्षक हो सकता है। किसी एप्लिकेशन द्वारा उत्पन्न की जा सकने वाली सभी त्रुटियों को बचाने से उसे क्रैश होने से रोका जा सकेगा। (हम यहां 100% अपटाइम लेकर आए हैं!) हालाँकि, यह बहुत सारी समस्याएं पैदा कर सकता है। <पी> अपवाद वर्ग रूबी में मुख्य अपवाद वर्ग है। अन्य सभी अपवाद इस वर्ग के उपवर्ग हैं; यदि अपवाद बचाया जाता है तो सभी त्रुटियाँ पकड़ी जाएँगी। <पी> दो अपवाद जिन्हें अधिकांश एप्लिकेशन बचाना नहीं चाहेंगे, वे हैं सिग्नलएक्सेप्शन और सिस्टमएक्सिट। <पी> सिग्नलएक्सेप्शन का उपयोग तब किया जाता है जब कोई बाहरी स्रोत एप्लिकेशन को रुकने के लिए कह रहा हो। यह ऑपरेटिंग सिस्टम हो सकता है जब वह बंद करना चाहता हो, या कोई सिस्टम प्रशासक हो सकता है जो एप्लिकेशन को बंद करना चाहता हो। उदाहरण <पी> SystemExit का उपयोग तब किया जाता है जबexit रूबी एप्लिकेशन से कॉल किया जा रहा है। जब इसे उठाया जाता है तो डेवलपर चाहता है कि एप्लिकेशन बंद हो जाए। उदाहरण <पी> यदि हम अपवाद को बचाते हैं और ये अपवाद तब उठाए जाते हैं जब कोई एप्लिकेशन वर्तमान में begin ... rescue ... end चला रहा हो ब्लॉक करें यह बाहर नहीं निकल सकता। <पी> सामान्य परिस्थितियों में अपवाद को बचाना आम तौर पर एक बुरा विचार है। अपवाद को बचाते समय, आप सिग्नलएक्सेप्शन और सिस्टमएक्सिट को काम करने से रोकेंगे, लेकिन कुछ नाम रखने के लिए लोडएरर, सिंटैक्सएरर और नोमेमोरीएरर को भी रोकेंगे। इसके बजाय अधिक विशिष्ट अपवादों को बचाना बेहतर है। परीक्षणों में विफलता
<पी> जब अपवाद कोrescue Exception => e का उपयोग करके बचाया जाता है , आपके एप्लिकेशन के अलावा अन्य चीज़ें टूट सकती हैं। परीक्षण सूट वास्तव में कुछ त्रुटियाँ छिपा सकता है। <पी> मिनिटेस्ट और आरएसपीईसी अभिकथनों में जो विफल हो जाते हैं, परीक्षण में विफल होने पर आपको विफल अभिकथन के बारे में सूचित करने के लिए एक अपवाद उठाया जाएगा। जब वे ऐसा करते हैं, तो वे अपवाद से उपवर्गित अपने स्वयं के कस्टम अपवाद उठाते हैं। <पी> यदि अपवाद को किसी परीक्षण या एप्लिकेशन कोड में बचाया जाता है, तो यह एक दावे की विफलता को शांत कर सकता है। अपवादों की अपेक्षा
<पी> कुछ कोड अपवाद बढ़ाने के लिए होते हैं। एक परीक्षण सूट में अपवादों को शांत करना संभव है ताकि उनके उठाए जाने पर परीक्षण विफल न हो। <पी> हालाँकि, यह परीक्षण नहीं करता है कि कोई अपवाद उठाया गया था या नहीं। जब अपवाद नहीं उठाया जाता है, तो आपका परीक्षण यह बताने में सक्षम नहीं होगा कि व्यवहार अभी भी सही है या नहीं। <पी> यह दावा करना संभव है कि क्या अपवाद उठाया गया है, और यदि नहीं, तो कौन सा अपवाद उठाया गया था।अपवाद को पुनः बढ़ाएं
<पी> किसी एप्लिकेशन को केवल तभी अपवाद वर्ग के रूप में श्रृंखला में ऊपर के अपवादों को कैप्चर करना चाहिए जब कोई बहुत अच्छा कारण हो। उदाहरण के लिए, जब कोड के किसी ब्लॉक से बाहर निकलने से पहले कुछ सफाई शामिल होती है, जैसे अस्थायी फ़ाइलों को हटाना जिन्हें वास्तव में हटाने की आवश्यकता होती है। <पी> एक सिफ़ारिश यह है कि जब आपको अपवाद को पूरी तरह से बचाना हो, तो त्रुटि से निपटने के बाद इसे फिर से उठाएँ। इस तरह रूबी अपवाद प्रबंधन बाद में प्रक्रिया के भाग्य का फैसला कर सकता है।पता नहीं कि क्या बचाया जाए?
<पी> जैसा कि पहले उल्लेख किया गया है, यह स्पष्ट होना अच्छा है कि किन त्रुटियों को बचाया जाए। <पी> जब आप अनिश्चित हों कि कोई ऑपरेशन कौन से अपवाद उत्पन्न कर सकता है, तो मानक त्रुटि को बचाना शुरू करने के लिए एक अच्छी जगह हो सकती है। अपने कोड को विभिन्न परिदृश्यों में चलाएँ और देखें कि यह क्या अपवाद उत्पन्न करता है। <पी> हर बार जब आपका सामना किसी नए अपवाद से होता है, तो उन अपवादों या उसके प्रासंगिक मूल वर्ग के लिए विशिष्ट बचाव मामले जोड़ें। बहुत सारे अपवादों को बचाने की तुलना में यह स्पष्ट करना बेहतर है कि क्या बचाया जाए। <पी> यह रूबी में अपवाद प्रबंधन पर हमारे प्राइमर का समापन करता है। यदि आप अधिक जानना चाहते हैं, या कोई विशिष्ट प्रश्न है तो हमें @AppSignal पर बताएं। यदि आप बेहतर जानकारी प्राप्त करना चाहते हैं कि आपके ऐप में कहां और कितनी बार अपवाद उठाए गए हैं, तो AppSignal को आज़माएं।
