फेंकने के लिए अपवाद किस typeo आप एक केवल पढ़ने के लिए संपत्ति से फेंक जब वस्तु है कि मान देने के लिए इस्तेमाल किया जा रहा अशक्तक्या अपवाद के प्रकार
public class TestClass
{
SomeObject obj;
public string NameOfObject
{
get
{
if(obj == null)
{ // what exception type to throw here }
return obj.Name;
}
}
एक InvalidOperationException मैं इस मामले में उपयोग करता हूं, क्योंकि संपत्ति की पहुंच ऑब्जेक्ट की वर्तमान स्थिति के लिए मान्य नहीं है।
एमएसडीएन दस्तावेज के अनुसार:
"ऑब्जेक्ट की वर्तमान स्थिति के लिए विधि कॉल अमान्य होने पर अपवाद को फेंक दिया गया है।"
भी:
"अमान्य ऑपरेशन अपवाद का उपयोग उन मामलों में किया जाता है जब किसी विधि को लागू करने में विफलता अमान्य तर्कों के अलावा अन्य कारणों से होती है।" आप किसी विशेष कोड जोड़ फ्लॉप, तो thats:
इस मामले obj में एक तर्क है, जिसके कारण मैं दुबला होता "InvalidOperationException" की ओर
कारण है कि मैं एक NullReferenceException यहां फेंक नहीं होता नहीं है अपवाद है कि "नेट" फेंक देगा, तो अनावश्यक कोड क्यों जोड़ें?
है आप कहीं कह रहे हैं जब तक कि इस गुण कभी नहीं होगा शून्य हो, आपको अपवाद फेंकने की आवश्यकता क्यों होगी?
यह कहकर कि, यदि आपने इसकी गारंटी दी है, तो मैं InvalidOperationException फेंक दूंगा।
InvalidOperationException
अपवाद है जब एक विधि कॉल वस्तु की वर्तमान स्थिति के लिए अमान्य है कि फेंक दिया जाता है।
मैं InvalidOperationException फेंक दूंगा।
ArgumentNullException मैं केवल तभी फेंक देता हूं यदि विधियों के पैरामीटर शून्य हैं।
यदि विधियों पैरामीटर एक अमान्य स्थिति में है तो मैं ArgumentException फेंक देता हूं।
यदि आप अपना स्वयं का संदेश पारित किए बिना 'नया अवैध ऑपरेशन अपवाद() 'करते हैं, तो डिफ़ॉल्ट संदेश" ऑपरेशन वर्तमान स्थिति के कारण मान्य नहीं है ऑब्जेक्ट। ", जो बिल्कुल सही है। विस्तृत जानकारी के लिए –
+1;) – Khh
आपको NullReferenceException को फेंकना नहीं चाहिए। यह उन स्थितियों के लिए आरक्षित है जब एक शून्य वस्तु को संदर्भित किया जाता है। इस मामले में, यदि आप NullReference को फेंकना चाहते थे, तो आप ओबज के नाम तक पहुंचने का प्रयास करते समय भी नल चेक आउट छोड़ सकते हैं और फ्रेमवर्क को आपके लिए फेंक सकते हैं।
मैं इसके बजाय InvalidOperationException फेंक दूंगा।
+1 क्यों नल रेफरेंस एक्सेप्शन – Khh
मैं एक InvalidOperationException फेंक चाहते हैं, लेकिन केवल तभी: - यह कानूनी है objnull होने के लिए, और यह इस बात के लिए जाँच करने के लिए उपयोगकर्ता की जिम्मेदारी, या है - यह कानूनी obj में null होने के लिए नहीं है पहली जगह
यदि उपरोक्त में से न तो मामले (जो है, यह कानूनी है objnull होने के लिए, और उपयोगकर्ता कोड स्पष्ट रूप से उपयोग करने से पहले यह जांच करने के लिए आवश्यक नहीं है है (यानी, obj != null एक वर्ग अपरिवर्तनीय है) संपत्ति), तो मैं बिल्कुल नहीं फेंक दूंगा बल्कि null लौटाऊंगा।
मैं डिज़ाइन को संशोधित इतना है कि इस राज्य में पहली जगह अर्थात obj में मौजूद नहीं कर सकते हैं रिक्त है। आम तौर पर एक एपीआई परिप्रेक्ष्य से आप अच्छे विश्वास में एक गेटर को कॉल करने में सक्षम होना चाहिए कि यह किसी अज्ञात स्थिति में होने वाली वस्तु के परिणामस्वरूप उड़ा नहीं जाएगा।
उदाहरण के लिए, क्यों एक निर्माता पैरामीटर के रूप में 'SomeObject obj' है और निर्माण के बिंदु पर तर्क सत्यापन का उपयोग नहीं। इससे यह सुनिश्चित होगा कि 'ओब्जे' की स्थिति हमेशा सही होती है यानी निर्माण के बाद गैर-शून्य।
कई पैटर्न है कि है कि एक वस्तु एक सही राज्य जब यह उपयोगकर्ता के लिए उपलब्ध हो जाता है सुनिश्चित करने के लिए इस्तेमाल किया जा सकता हैं।
सभी ने स्पष्ट रूप से कवर किया है, इसलिए यहां एक और विकल्प है।
अपने वर्ग कुछ तरीके से प्रारंभ किया जाना चाहिए (अपने SomeObject कुछ बिंदु पर सेट किया जाना चाहिए), ISupportInitialize को लागू करने पर विचार करें। यह आपकी कक्षा के उपयोगकर्ताओं को इंगित करता है कि यह EndInit() से पहले वैध स्थिति में नहीं है। दुर्भाग्यवश, कोई पूर्ववर्ती सामान्य NotInitializedException नहीं है जिसका आप उपयोग कर सकते हैं (कुछ हैं लेकिन कुछ नामस्थानों के लिए विशिष्ट हैं), इसलिए मैं इस तरह के अपवाद के निर्माण के साथ इंटरफ़ेस के कार्यान्वयन को जोड़ने का सुझाव दूंगा।
उपयोगकर्ताओं को पहले BeginInit() पर कॉल करना होगा, फिर इंस्टेंस कॉन्फ़िगर करें, फिर EndInit() पर कॉल करें। EndInit() पर कॉल पर, अपने उदाहरण की स्थिति की जांच करें। यदि यह सही ढंग से इंटिलाइज्ड नहीं है, तो आप एक अवैधऑपरेशन अपवाद फेंक सकते हैं। यदि उपयोगकर्ता प्रारंभ होने से पहले आपके उदाहरण का उपयोग करने का प्रयास करते हैं, तो आप अपना NotInitializedException फेंक देंगे।
यह थोड़ा और काम है, लेकिन लाभ यह है कि आप अपने उपयोगकर्ताओं के लिए व्यापक "सफलता का गड्ढा" बना रहे हैं, यह सुनिश्चित करना कि वे तेज़ और जल्दी में विफल होने और आपके प्रकार की परिभाषा के अनुसार सही ढंग से अपने वर्गों का उपयोग करें (इंटरफ़ेस आप जो अपेक्षा करते हैं उस पर बहुत स्पष्ट है)। यह आपको कक्षा के उपयोग के तरीके के बारे में दस्तावेज के लिए, "बोलने" के लिए भी अधिक "कमरा" प्रदान करता है।
का उपयोग नहीं करने के स्पष्टीकरण के लिए मैं ISupportInitialize से परिचित हूं और इसका उपयोग DI संदर्भों (यानी संपत्ति इंजेक्शन) में है। मुझे इतना यकीन नहीं है कि यह जैव प्रोग्रामिक \ उपयोगकर्ता एपीआई के रूप में बहुत अच्छी तरह से है। यह पैटर्न WinForms और WPF में बहुत उपयोग किया जाता है, लेकिन मुझे संदेह होगा कि कुछ लोगों को इसके बारे में भी पता है, इसलिए 'सफलता का गड्ढा' कोण के बारे में इतना निश्चित नहीं है। डिफॉल्ट कन्स्ट्रक्टर की आवश्यकता के कारण यूआई ढांचे में इस पैटर्न का उपयोग किया जाता है। एक उपयोगकर्ता एपीआई में यह आवश्यक नहीं है, अन्य तंत्र का उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि एक वस्तु सही स्थिति के साथ बनाई गई है उदा। कन्स्ट्रक्टर पैरामीटर और तर्क सत्यापन। –
@chi सब सच है। बस यह पता चला कि पंद्रह "अमान्य ऑपरेशन अपवाद" के बाद भी कम से कम एक विकल्प के लिए कमरा था। गड्ढा बड़ा है, इमो, क्योंकि यह उपयोगकर्ताओं को उदाहरण "स्थापित" करने के लिए मजबूर करता है, जिसका अर्थ है कि उपयोगकर्ताओं को यह समझना होगा कि इसका वास्तव में क्या अर्थ है।इससे थोड़ा स्पष्ट है या उस पद्धति/संपत्ति ने अपवाद फेंक दिया है यदि आपने अभी तक कुछ नहीं किया है। – Will
सहमत - मुझे लगता है कि "अवैधऑपरेशन अपवाद" फेंकने से समस्या को हल करने के बेहतर तरीके हैं। मैं वैकल्पिक समाधान कोण पर भी था। –
आपके द्वारा प्रदान किए गए कोड को देखते हुए और अपनी डिज़ाइन धारणाओं के बारे में कुछ भी नहीं जानते, मैं कहूंगा कि आपको obj == null का परीक्षण नहीं करना चाहिए और ढांचे को NullReferenceException फेंकने दें। तो आप यह परीक्षा क्यों चाहते हैं? एक कारण यह है कि मैं सोच सकता हूं कि आप डिबगिंग के लिए एक और अधिक सार्थक त्रुटि संदेश चाहते हैं, लेकिन फिर आपको Debug.Assert(obj != null, "Your message here") का उपयोग करना चाहिए।
शायद यह इस विषय के लिए एक सवाल है, लेकिन क्यों एक फेंक दिया? – 4imble
महत्वपूर्ण नोट: एक संपत्ति को पढ़ा जाने पर अपवाद फेंकना चाहिए (लगभग)। (अमान्य ऑपरेशन वह है जिसे आप कर सकते हैं)। http://msdn.microsoft.com/en-us/library/bb386039.aspx – FastAl