अपवाद बनाम सत्यापन

Question

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

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

Answer 1

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

तो एक संपत्ति सेटर के लिए, यदि सेटटर संपत्ति सेट करने में असमर्थ है, तो उसे अपवाद फेंकना चाहिए।

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

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

Answer 2

पकड़ना और पुनर्स्थापन करना सबसे बुरी चीज है। कोशिश करने के लिए महंगा है, अगर आप बस बिंदु क्या पुनर्स्थापित करने जा रहे हैं? उदाहरण के लिए यदि आप उन्हें लॉग इन करने की आवश्यकता है तो आप catch unhandled exceptions with the global.asax कर सकते हैं।

मान्यता के संदर्भ में, एक वेब नजरिए से मैं हमेशा दिनांकों regex प्रमाणकों उपयोग करते हैं, इन आग ग्राहक और सर्वर साइड इसलिए मुझे पता है जब एक

if(Page.IsValid) 

ब्लॉक के अंदर im कि मेरे txtDate.Text एक वैध है तारीख, इसलिए मैं जांच परेशान नहीं करता क्योंकि यह सिर्फ अपमानजनक है।

Answer 3

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

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

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

Answer 4

यह वास्तव में आपके आवेदन के तर्क पर निर्भर करता है। अपवाद केवल उन परिस्थितियों के लिए फेंक दिया जाना चाहिए जो असाधारण हैं। सत्यापन की तरह कुछ के लिए यह अमान्य डेटा के लिए सहिष्णुता पर निर्भर करता है।

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

यदि आप किसी डेटाबेस या लॉग फ़ाइल से पूर्व-तैयार दस्तावेज़ों को संसाधित कर रहे हैं तो दस्तावेज़ के अमान्य होने के बाद शायद यह ठीक नहीं है और सिस्टम में भ्रष्ट डेटा हो सकता है। जब ऐसा होता है तो आपको फेंकना चाहिए।

Answer 5

मुझे लगता है कि यह निर्भर करता है कि दिनांक मूल्य कहां से आते हैं। यदि यह उपयोगकर्ता इनपुट या किसी अन्य स्रोत से आता है जहां 'अमान्य' तिथियां दर्ज करना पूरी तरह से संभव है, तो सत्यापन करने का तरीका होगा। दूसरी तरफ, यदि कोई पूर्व कारण नहीं है कि डेटा मान अमान्य क्यों हो सकते हैं, तो अपवाद फेंकना उचित है।