अपवादों को फेंकने और संभालने पर विचार

अपने व्यक्तिगत अनुभव के आधार पर, मैंने अपवादों के साथ काम करने की एक निश्चित अवधारणा विकसित की। यह अवधारणा व्यावसायिक प्रक्रियाओं के आधार पर अनुप्रयोगों के लिए "तेज" है। सिस्टम और अन्य कार्यक्रमों के लिए, यह अप्रभावी हो सकता है। क्योंकि मैं मुख्य रूप से .Net का उपयोग करता हूं, फिर .Net प्लेटफ़ॉर्म के लिए समावेशन के उदाहरण दिए जाते हैं।



अवधारणा तालिका के रूप में प्रस्तुत की गई है:

अपवाद फेंकने का कारण	विवरण	अपवर्जन वर्ग (.Net मंच)	कैसे एक अपवाद को संभालने के लिए
1. व्यापार प्रक्रिया के नियमों का उल्लंघन	आपके सिस्टम के किसी भी आंतरिक नियमों का उल्लंघन। उदाहरण के लिए, शून्य शेष राशि वाले खाते से धन निकालने का प्रयास। इसके अलावा, नियम लचीले हो सकते हैं: कुछ प्रकार के खातों के लिए, आपको नकारात्मक जाने की अनुमति दी जा सकती है।	आपको अपना वर्ग लागू करना होगा, अपवाद का उत्तराधिकारी (पहले ApplicationException से विरासत में लेने की सिफारिश की गई थी, अब बदल गया है)। आमतौर पर, एक अपवाद में उपयोगकर्ता के अनुकूल जानकारी होती है।	अपने सिस्टम के आंतरिक नियमों के अनुसार प्रक्रिया करें। ज्यादातर अक्सर, वर्तमान ऑपरेशन को संसाधित करना बंद कर देते हैं और उपयोगकर्ता को एक संदेश जारी करते हैं। आपको लॉग फ़ाइल में इन प्रकार के अपवाद लिखने की आवश्यकता नहीं है।
2. गलत डेटा	2.1। गलत उपयोगकर्ता इनपुट। उदाहरण के लिए, एक संख्या के बजाय एक पत्र दर्ज किया जाता है।	यदि संभव हो, तो एक अपवाद को फेंकने के बिना संभालें (एक सरल जांच या ट्रायपर्स का उपयोग करें)। अन्यथा, 2.2 के समान।	उपयोगकर्ता को संकेत दें कि कौन सा डेटा सही नहीं है। उन्हें ठीक करने का अवसर प्रदान करें। आपको लॉग फ़ाइल में लिखने की आवश्यकता नहीं है।
	2.2। डेटा स्रोत (वेब ​​सेवा, फ़ाइल, रजिस्ट्री, डेटाबेस) से गलत डेटा। उदाहरण के लिए, XML प्रारूप के बजाय सादा पाठ प्राप्त होता है।	कोई स्पष्ट नियम नहीं हैं। FormatException, InvalidDataException, आदि। आमतौर पर .Net एक विशेष अपवाद वर्ग का परिचय देता है जो डेटा गलत होने पर होता है। उदाहरण: configurationException, XmlException, SqlException, SqlTypeException, WebException। हालांकि, इन अपवादों की घटना का मतलब यह नहीं है कि समस्या डेटा गलतता है (अन्य कारण हैं)। लेकिन ArgumentException, InvalidOperationException, आदि, अच्छी तरह से लागू हो सकते हैं। यह अपवाद के संचालन को बहुत जटिल करता है।	दो विकल्प: या तो डेटा प्रदाता प्रोटोकॉल का उल्लंघन करता है, या ग्राहक ने प्रोटोकॉल के अनुसार डेटा के प्रसंस्करण को पूरी तरह से लागू नहीं किया है। यदि डेटा प्रदाता पर्याप्त नहीं है, तो आप एक "बैसाखी" स्थानापन्न कर सकते हैं। यदि आपका "बैसाखी" समस्या को हल करने में सक्षम था, तो आपको लॉग फ़ाइल में लिखने की आवश्यकता नहीं है। अन्यथा, लॉग फ़ाइल में विवरण लिखें और समस्या को 2 स्तरों में से एक पर हल करें।
3. अमान्य कोड	3.1। अनुबंध का उल्लंघन।	IndexOutOfRangeException, NullReferenceException, AccessViolationException, ArgumentException, ArgumentNullException, ArgumentOutOfRangeException, InvalidCastException, आदि।	लॉग फ़ाइल में अपवाद का विवरण लिखें, डेवलपर को लॉग भेजें। ऐसे अपवाद डेवलपर की गलती का 100% हैं। उपयोगकर्ता को त्रुटि के बारे में चेतावनी दें। त्रुटि कहां हुई, इसके आधार पर तय करें कि प्रोग्राम को बंद करना है (यदि डेटा क्षतिग्रस्त हो सकता है)। लॉग डेटा के आधार पर कोड में एक त्रुटि को ठीक करें और प्रोग्राम संस्करण को अपडेट करें।
	3.2। उल्लंघनकर्ता का उल्लंघन।	InvalidOperationException
4. सिस्टम त्रुटि (अक्सर एक हार्डवेयर समस्या के कारण)।		हटाने योग्य नहीं: * ExecutionEngineException, StackOverflowException, OutOfMemoryException। 99% मामलों में, इन अपवादों को संभालना संभव नहीं है।	99% मामलों में, इसे बिल्कुल भी संसाधित न करें। आप लॉग में अपवाद डेटा लिखने का प्रयास कर सकते हैं।

मैं ध्यान देता हूं कि यह संरचना बुनियादी अवधारणाओं पर आधारित है:



1. हार्डवेयर।

2. सॉफ्टवेयर। बदले में, सॉफ्टवेयर समस्याओं को 2 उपवर्गों में विभाजित किया जाता है: डेटा समस्या और कोड समस्या।



इसलिए, सिद्धांत रूप में, मैं कुछ भी नया नहीं आया था।



यह ध्यान देने योग्य है कि एक श्रेणी में त्रुटियां दूसरे श्रेणी में अपवाद हो सकती हैं। उदाहरण के लिए, गलत कोड StackOverflowException का कारण हो सकता है। हालांकि, गलत डेटा आदर्श रूप से गलत कोड त्रुटियों या सिस्टम त्रुटियों का कारण नहीं होना चाहिए।



मैं इस विषय पर विचार सुनना चाहूंगा।