स्विच स्टेटमेंट में डिफ़ॉल्ट मामले पर NotImplementedException फेंकना

Question

क्या मुझे default पर फेंकना चाहिए, अगर मेरे पास सभी संभावित एनम प्रकारों के मामले हैं?

Answer 1

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

लेकिन अब आपको संदर्भ पर विचार करना होगा।

क्या विधि निजी है, और केवल आपकी कक्षा पुस्तकालय या एप्लिकेशन के सदस्यों द्वारा ही सुलभ है? यदि ऐसा है, तो यह एक कोडिंग त्रुटि है जो पहले कभी नहीं होनी चाहिए। जोर दें और असफल हो जाएं।

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

यह याद रखना महत्वपूर्ण है कि फ्रेमवर्क में गणनाओं की गणना नहीं की जाती है। मैं निर्दिष्ट कर सकता हूं कि एक विधि को पर्यावरण के प्रकार के पैरामीटर की आवश्यकता होती है। SpecialFolder; लेकिन यह किसी भी 32-बिट पूर्णांक मान को स्वीकार करेगा।

तो, संक्षेप में, यदि आपकी विधि सार्वजनिक उपभोग के लिए है, हाँ, हर तरह से, फेंक दें। यदि यह सार्वजनिक उपभोग के लिए नहीं है, Assert।

Answer 2

यह वास्तव में विशिष्ट प्रक्रिया पर निर्भर करता है, लेकिन हां, डिफ़ॉल्ट में प्रतिक्रिया देने की अच्छी प्रक्रिया है: अगर कुछ ऐसा नहीं होना चाहिए था।

Answer 3

यह एक उचित विकल्प की तरह लगता है।

व्यक्तिगत रूप से, मैं एक नया प्रकार का अपवाद (शायद InvalidEnumException बनाउंगा या इसे एक और नाम दूंगा जो समर्थन टीम को समझ में आएगा) और इसे फेंक दें।

Answer 4

मैं ApplicationException फेंक दूंगा क्योंकि यदि आपका कोड डिफ़ॉल्ट तक पहुंचता है और आपको इसकी उम्मीद नहीं होती है तो इसका मतलब है कि आपके कोड में कुछ ऐसा व्यवहार नहीं कर रहा है जहां आप सोच रहे हैं।

Answer 5

मैं कहूंगा कि कम से कम आपको Debug.Fail() डालना चाहिए।

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

Answer 6

शायद नहीं कार्यान्वित अपवाद, लेकिन ArgumentException। यह वास्तव में इस बात पर निर्भर करेगा कि आप इसका उपयोग कहां कर रहे हैं।

Answer 7

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

Answer 8

यदि आपने अपवाद फेंक दिया तो क्या होगा? स्विच स्टेटमेंट को किस संदर्भ में निष्पादित किया जा रहा है? क्या वह स्थिति कभी होनी चाहिए? क्या यह कभी भी उत्पादन कोड में रन-टाइम पर होना चाहिए? क्या आपके यूनिट परीक्षण इस स्थिति को कवर करते हैं? यदि ऐसा है, तो शायद एक जोर बेहतर होगा।

Answer 9

आपको सबसे पहले यह समझना चाहिए कि अगर आपको ज्ञात मामलों के बाहर कोई मूल्य मिल गया है तो इसका क्या अर्थ होगा- परिवर्तनीय को प्रतिनिधित्व पर स्विच किया जा रहा है? फिर आप बस एक अपवाद प्रकार का उपयोग कर सकते हैं जो वास्तव में क्या हो रहा है।

Answer 10

यह वास्तव में निर्भर करता है।

• NotImplementedException मेरे लिए कुछ भी पसंद है। इसका मतलब है कि कोई कोड कोड खत्म करने के बाद बाद में आएगा। हालांकि मुझे नहीं लगता कि यह डिफ़ॉल्ट मामला है जो नहीं होना चाहिए।

• जब आप ऑब्जेक्ट की स्थिति की जांच कर रहे हैं तो आप InvalidOperationException पर विचार कर सकते हैं। आपकी विधि केवल मौजूदा मामलों के साथ काम करने के लिए डिज़ाइन की गई है।

• जब आप इनपुट पैरामीटर ArgumentException पर भेदभाव करते हैं तो हमेशा उपयुक्त होता है।

• अन्य मामलों में मैं NotSupportedException पसंद करता हूं। यह थोड़ा इंगित करता है कि मंच या संस्करण के साथ कुछ गलत है। और कोड के असंगत संस्करण समस्या की वास्तविक जड़ है जब स्विच का डिफ़ॉल्ट मामला नहीं होना चाहिए।