एक पैरामीटर के साथ एक कन्स्ट्रक्टर के लिए, क्या पैरामीटर शून्य/खाली होने पर कन्स्ट्रक्टर के अंदर एक ArgumentNullException फेंकना ठीक है? या, इसे उस विधि में फेंक दिया जाना चाहिए जो वास्तव में तर्क का उपयोग करता है? धन्यवाद।कन्स्ट्रक्शन में ArgumentNullException फेंकता है?
हां, यदि यह पूरी तरह से आवश्यक है तो अपवाद फेंक दें। आपको बाद में अपवाद फेंकना नहीं चाहिए।
हमेशा "Fail Early Principle" याद रखें। अवधारणा अब विफल हो रही है, इसलिए आप समय डिबगिंग बर्बाद नहीं करते हैं या अप्रत्याशित सिस्टम कार्यक्षमता का अनुभव नहीं करते हैं।
वैकल्पिक रूप से आप "" के लिए एक ArgumentException और null के लिए ArgumentNullException भी फेंक सकते हैं। किसी भी मामले में सुनिश्चित करें कि आप एक वैध अपवाद संदेश फेंक दें।
हमेशा प्रबंध अपवाद के लिए एक अच्छा संदर्भ लेख: क्या @Steve Michelotti कहा पर Good Exception Management Rules of Thumb
साइड नोट
Contract.Requires<ArgumentNullException>(inputParemeter!= null, "inputparameter cannot be null");
Contract.Requires<ArgumentException>(inputParemeter!= "", "inputparameter cannot be empty string");
वैकल्पिक रूप से
Contract.Requires<ArgumentNullException>(!string.IsNullOrEmpty(inputParemeter), "inputparameter cannot be null or empty string");
यह कैसा लगता है, आप बाद में किसी अन्य विधि में उपयोग के लिए कक्षा द्वारा आयोजित कन्स्ट्रक्टर में पैरामीटर में पास करते हैं। यदि आप वास्तव में कन्स्ट्रक्टर में तर्क का उपयोग नहीं कर रहे हैं, तो आपको शायद इस तर्क का उपयोग करने के बारे में सोचें कि वास्तव में इसका उपयोग कर रहा है।
मैं कर सकता था अगर मैं कर सकता था, लेकिन यह एक इंटरफेस के आधार पर निष्पादित कार्यों की एक श्रृंखला का हिस्सा है, इसलिए, मैं विधि हस्ताक्षर संशोधित नहीं कर सकता। –
उस स्थिति में, मैं हर किसी के साथ सहमत हूं जो कि कन्स्ट्रक्टर में विफल होने का निश्चित रूप से सबसे अच्छा विकल्प है। कोड अनुबंधों के लिए –
कन्स्ट्रक्टर में इसे फेंकना ठीक है - .NET ढांचे में कई कक्षाएं हैं जो ऐसा करती हैं। इसके अतिरिक्त, इसके लिए code contracts देखें।
+1। – Nix
मैं उस संपत्ति में चेक डाल दूंगा जिसे आपने कन्स्ट्रक्टर कहलाते समय सेट किया था ... इस तरह अपवाद सभी मामलों में फेंक दिया जाएगा।
कोई संकेत नहीं है कि एक संपत्ति निर्माता द्वारा निर्धारित किया जा रहा है। –
हाँ, लेकिन यह पकड़ा जाएगा? क्लास क्रियाएं आम तौर पर क्लास सृजन की कोशिश करने वाले ब्लॉक में शामिल नहीं होती हैं। – Canacourse
एक और अच्छा नियम "जल्दी विफल" है। विशेष रूप से पैरामीटर और तर्कों को प्रोसेस करने के लिए, त्रुटि का पता लगाने के लिए सबसे पहले मौके पर, या जब त्रुटि होती है तो स्पेस-टाइम में बिंदु के रूप में जितना संभव हो सके। –
आप सही हैं! मैं सही सिद्धांत के "नाम" को खोजने के लिए संघर्ष कर रहा था। – Nix