कार्यों के अंदर या बाहर ब्लॉक को पकड़ने का प्रयास करें और

Question

को सौंपने में त्रुटि यह भाषा विशिष्ट से अधिक सामान्य उद्देश्य प्रोग्रामिंग प्रश्न है। मैंने कोशिश करने और पकड़ने के लिए कई appraoches देखा है।

एक तुम क्या जो कुछ डेटा पर पूर्व प्रसंस्करण की जरूरत है, उचित तर्क के साथ एक समारोह फोन और एक आज़माएं/कैच ब्लॉक में लपेट है।

अन्य बस एक समारोह एक सही/गलत झंडा लौटने अगर त्रुटियां हुईं समारोह के साथ, समारोह के भीतर डेटा गुजरती हैं और कोशिश कैच पर भरोसा करते हैं कॉल करने के लिए है।

तीसरा फ़ंक्शन के अंदर और अंदर के प्रयास को पकड़ने वाला संयोजन है। हालांकि यदि फंक्शंस फ़ंक्शन कैच करने की कोशिश करता है, तो यह फ़ंक्शन के बाहर पकड़ने के लिए प्रयास ब्लॉक के लिए एक और अपवाद फेंकता है।

त्रुटि नियंत्रण के लिए या यदि इन तरीकों में से पेशेवरों/विपक्ष पर कोई विचार वहाँ एक स्वीकृत मानक है? मेरे गुगल निंजा कौशल ने मुझे इस पर सटीक डेटा खोजने में विफल कर दिया है।

Answer 1

सामान्य रूप से, अगर इसे वास्तव में संभाला जा सकता है तो अपवाद केवल तभी पकड़ा जाना चाहिए।

इसे लॉग इन करने के अलावा किसी भी उद्देश्य के लिए अपवाद को पकड़ने का कोई मतलब नहीं है। अपवाद यह है कि अपवादों को "शीर्ष स्तर" पर पकड़ा जाना चाहिए ताकि इसे लॉग किया जा सके। अन्य सभी कोड अपवादों को उस कोड को प्रसारित करने की अनुमति दे सकते हैं जो उन्हें लॉग करेगा।

Answer 2

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

Answer 3

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

Answer 4

अपवादों को पकड़ने का एकमात्र सवाल यह है कि "कुछ करने के लिए कई रणनीतियां हैं?"

कुछ फ़ंक्शंस अर्थपूर्ण रूप से कुछ अपवादों को पकड़ सकते हैं और उन ज्ञात अपवादों की स्थिति में वैकल्पिक रणनीतियों को आजमा सकते हैं।

अन्य सभी अपवाद फेंक दिए जाएंगे।

यदि कोई वैकल्पिक रणनीति नहीं है, तो अपवाद को आसानी से फेंक दिया जाएगा।

शायद ही कभी आप एक समारोह को पकड़ने (और चुप्पी) अपवादों को चाहते हैं। एक अपवाद का मतलब है कि कुछ गलत है। आवेदन - पूरी तरह से - अनचाहे अपवादों से अवगत होना चाहिए। इसे कम से कम लॉग इन करना चाहिए, और शायद और भी कुछ करना चाहिए: बंद करें या शायद पुनरारंभ करें।

Answer 5

मुझे लगता है कि इस बारे में सोचने का सबसे अच्छा तरीका प्रोग्राम राज्य के मामले में है। आप प्रोग्राम स्थिति को नुकसान पहुंचाने के लिए असफल ऑपरेशन नहीं चाहते हैं। This paper "अपवाद सुरक्षा" की अवधारणा का वर्णन करता है।

सामान्यतः, आपको सबसे पहले यह तय करने की आवश्यकता होती है कि किसी फ़ंक्शन को अपवाद सुरक्षा की किस स्तर की गारंटी की आवश्यकता है। स्तरों

• बेसिक Guarnantee हैं
• मजबूत गारंटी
• NoThrow गारंटी

बुनियादी गारंटी का अर्थ है कि एक अपवाद या अन्य त्रुटि का सामना करने में, कोई संसाधन लीक कर रहे हैं, मजबूत गारंटी कहती है कि कार्यक्रम राज्य को अपवाद से पहले वापस ले जाया जाता है, और विधियों को कभी अपवाद नहीं फेंकते हैं।

जब मैं अप्रत्याशित, रनटाइम विफलता होती है तो मैं व्यक्तिगत रूप से अपवादों का उपयोग करता हूं। मेरे लिए अप्रत्याशित साधन है कि इस तरह की विफलता संचालन के सामान्य पाठ्यक्रम में नहीं होनी चाहिए। रनटाइम का अर्थ है कि त्रुटि मेरे नियंत्रण के बाहर कुछ बाहरी घटक की स्थिति के कारण है, क्योंकि मेरे हिस्से पर तर्क त्रुटियों के कारण। मैं तर्क त्रुटियों को पकड़ने के लिए ASSERT() का उपयोग करता हूं, और मैं अपेक्षित त्रुटियों के लिए बूलियन रिटर्न मानों का उपयोग करता हूं।

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

मूल गारंटी के लिए सी ++ तकनीक देखने के लिए, Google "RAII" (संसाधन अधिग्रहण प्रारंभिक है)। यह एक तकनीक है जहां आप किसी ऑब्जेक्ट में संसाधन को लपेटते हैं जिसका कन्स्ट्रक्टर संसाधन आवंटित करता है और जो विनाशक संसाधन को मुक्त करता है। चूंकि सी ++ अपवाद स्टैक को खोलते हैं, इसलिए यह गारंटी देता है कि अपवादों के सामने संसाधन मुक्त हो जाते हैं। आप इस तकनीक का उपयोग अपवाद के सामने कार्यक्रम स्थिति को वापस रोल करने के लिए कर सकते हैं। किसी ऑब्जेक्ट में बस "Commit" विधि जोड़ें, और यदि कोई वस्तु नष्ट होने से पहले प्रतिबद्ध नहीं है, तो "रोलबैक" ऑपरेशन चलाएं जो विनाशक में प्रोग्राम स्थिति को पुनर्स्थापित करता है।

Answer 6

मेरे सामने आने वाले अपवाद हैंडलिंग के आसपास कोई वास्तविक कठोर और तेज़ नियम नहीं हैं, हालांकि मेरे पास अंगूठे के कई सामान्य नियम हैं जिन्हें मैं लागू करना चाहता हूं।

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

अंततः ब्लॉक के भीतर एक निष्पादन फेंक न दें, आप मूल अपवाद खो देंगे और एक महत्वपूर्ण त्रुटि के साथ असली समस्या मुखौटा।

इसके अलावा यह उस कार्य पर निर्भर करता है जिसे आप कार्यान्वित कर रहे हैं। क्या आप एक पाश में हैं, क्या बाकी वस्तुओं को पुनः प्रयास किया जाना चाहिए या पूरी सूची निरस्त होनी चाहिए?

यदि आप अपवाद को पुनर्स्थापित करते हैं तो लॉगिंग से बचें क्योंकि यह आपके लॉग में शोर जोड़ देगा।