मेरे पास एक संपत्ति के लिए एक सरल सेटर विधि है और nullइस विशेष संपत्ति के लिए उपयुक्त नहीं है। मैं हमेशा इस स्थिति में फटा हुआ हूं: क्या मुझे IllegalArgumentExceptionए, या ए को फेंक देना चाहिए NullPointerException? Javadocs से, दोनों उपयुक्त लगते हैं। क्या किसी तरह का समझा हुआ मानक है? या यह सिर्फ उन चीजों में से एक है जो आपको करना चाहिए जो आप पसंद करते हैं और दोनों वास्तव में सही हैं?
जवाबों:
ऐसा लगता है जैसे एक के IllegalArgumentExceptionलिए कहा जाता है यदि आप nullएक अनुमत मूल्य नहीं होना चाहते हैं , और NullPointerExceptionफेंक दिया जाएगा यदि आप एक चर का उपयोग करने की कोशिश कर रहे थे जो कि निकला null।
IllegalArgumentExceptionजावा के Objects.requireNonNull (T) और अमरूद के Preconditions.checkNotNull (T) के साथ विरोधाभास है जो एक फेंकता है NullPointerException। हालांकि, जेसन कोहेन के उत्कृष्ट जवाब में बताया गया सही उत्तर निश्चित है और यह टिप्पणी अनुभाग है । IllegalArgumentException
आपको निम्नलिखित कारणों से IllegalArgumentException(IAE) का उपयोग करना चाहिए , न कि NullPointerException(NPE):
सबसे पहले, NPE JavaDoc उन मामलों को स्पष्ट रूप से सूचीबद्ध करता है जहाँ NPE उपयुक्त है। ध्यान दें कि उन सभी को रनटाइम द्वारा फेंक दिया जाता है जब nullअनुचित तरीके से उपयोग किया जाता है। इसके विपरीत, IAE JavaDoc अधिक स्पष्ट नहीं हो सकता है: "यह इंगित करने के लिए फेंक दें कि एक विधि एक अवैध या तार्किक तर्क पारित किया गया है।" हाँ, यह तुम हो!
दूसरा, जब आप स्टैक ट्रेस में एक NPE देखते हैं, तो आप क्या मानते हैं? शायद कि किसी ने dereferenced a null। जब आप IAE देखते हैं, तो आप अवैध मान में पारित स्टैक के शीर्ष पर विधि के कॉलर को मान लेते हैं। फिर, बाद की धारणा सच है, पूर्व भ्रामक है।
तीसरा, चूंकि आईएई स्पष्ट रूप से मापदंडों को मान्य करने के लिए डिज़ाइन किया गया है, इसलिए आपको इसे अपवाद के डिफ़ॉल्ट विकल्प के रूप में ग्रहण करना होगा, इसलिए आप इसके बजाय पीईपी क्यों चुनेंगे? निश्चित रूप से अलग व्यवहार के लिए नहीं - क्या आप वास्तव में NPE को IAE से अलग पकड़ने के लिए कॉलिंग कोड की अपेक्षा करते हैं और परिणामस्वरूप कुछ अलग करते हैं? क्या आप अधिक विशिष्ट त्रुटि संदेश संवाद करने का प्रयास कर रहे हैं? लेकिन आप ऐसा कर सकते हैं अपवाद संदेश पाठ में वैसे भी, जैसा कि आपको अन्य सभी गलत मापदंडों के लिए होना चाहिए।
चौथा, अन्य सभी गलत पैरामीटर डेटा IAE होंगे, तो लगातार क्यों नहीं? ऐसा क्यों है कि एक अवैध nullइतना विशेष है कि यह अन्य सभी प्रकार के अवैध तर्कों से अलग अपवाद के योग्य है?
अंत में, मैं अन्य उत्तरों द्वारा दिए गए तर्क को स्वीकार करता हूं कि जावा एपीआई के कुछ हिस्से इस तरह से एनपीई का उपयोग करते हैं। हालाँकि, Java API अपवाद प्रकारों से लेकर नामकरण सम्मेलनों तक सभी के साथ असंगत है, इसलिए मुझे लगता है कि केवल आँख बंद करके (आपके पसंदीदा भाग) Java API इन अन्य विचारों को ट्रम्प करने के लिए एक अच्छा पर्याप्त तर्क नहीं है।
Validate.notNull(कॉमन्स लैंग) और Preconditions.checkNotNull(अमरूद) दोनों एनपीई फेंक देते हैं :-(
checkArgument(arg != null), बस इसे वापस लाने की सुविधा के बिना, या आप बना सकते हैं। आपकी परियोजना के लिए एक स्थानीय उपयोगिता। " code.google.com/p/guava-lbooks/wiki/IdeaGraveyard
मानक फेंकना है NullPointerException। आम तौर पर अचूक "प्रभावी जावा" आइटम 42 (पहले संस्करण), आइटम 60 (दूसरे संस्करण), या आइटम 72 (तीसरे संस्करण) में संक्षिप्त रूप से चर्चा करता है "मानक अपवादों के उपयोग को अनुकूल करें":
"तर्क से, सभी गलत तरीके के चालान अवैध तर्क या अवैध स्थिति के लिए उबालते हैं, लेकिन अन्य अपवादों को कुछ प्रकार के अवैध तर्कों और राज्यों के लिए मानक रूप से उपयोग किया जाता है। यदि कोई कॉलर कुछ पैरामीटर में अशक्त गुजरता है, जिसके लिए शून्य मान निषिद्ध हैं, तो कन्वेंशन निर्धारित करता है। NullPointerException को IllegalArgumentException के बजाय फेंक दिया जाएगा। "
मैं सभी IllegalArgumentExceptionशून्य मानकों के लिए फेंकने के पक्ष में था, आज तक, जब मैंने java.util.Objects.requireNonNullजावा में विधि देखी। 7. इस विधि के साथ, करने के बजाय:
if (param == null) {
throw new IllegalArgumentException("param cannot be null.");
}तुम कर सकते हो:
Objects.requireNonNull(param);और NullPointerExceptionयदि आप इसे पास करते हैं तो यह फेक होगा null।
यह देखते हुए कि विधि सही धमाके के बीच है, java.utilमैं अपने अस्तित्व को एक बहुत मजबूत संकेत मानता हूं कि फेंकना NullPointerException"चीजों को करने का जावा तरीका है"।
मुझे लगता है कि मैं किसी भी दर पर तय किया गया हूं।
ध्यान दें कि हार्ड डिबगिंग के बारे में तर्क फर्जी है क्योंकि आप निश्चित रूप से NullPointerExceptionयह कहने के लिए एक संदेश प्रदान कर सकते हैं कि क्या अशक्त था और क्यों यह अशक्त नहीं होना चाहिए। जैसे के साथ IllegalArgumentException।
इसका एक अतिरिक्त फायदा NullPointerExceptionयह है कि, अत्यधिक प्रदर्शन क्रिटिकल कोड में, आप नल के लिए एक स्पष्ट जांच (और NullPointerExceptionएक अनुकूल त्रुटि संदेश के साथ) से दूर कर सकते हैं, और NullPointerExceptionजब आप नल पर एक विधि कहते हैं, तो आप स्वचालित रूप से भरोसा करेंगे। पैरामीटर। बशर्ते आप किसी विधि को शीघ्रता से कॉल करें (अर्थात तेजी से विफल), तो आपके पास अनिवार्य रूप से एक ही प्रभाव है, बस डेवलपर के लिए उपयोगकर्ता के अनुकूल नहीं है। ज्यादातर बार यह स्पष्ट रूप से जांचना बेहतर होता है और एक उपयोगी संदेश के साथ फेंकना इंगित करने के लिए कि कौन सा पैरामीटर अशक्त था, लेकिन यह बदलने का विकल्प अच्छा है कि यदि प्रदर्शन विधि / निर्माता के प्रकाशित अनुबंध को तोड़ने के बिना निर्धारित करता है।
Preconditions.checkNotNull(arg)भी एनपीई फेंकता है।
मैं JDK पुस्तकालयों, विशेष रूप से संग्रह और संगामिति (जोशुआ बलोच, डौग ली, के डिजाइन का पालन करता हूं, उन लोगों को पता है कि ठोस एपीआई कैसे डिजाइन करें)। वैसे भी, JDK समर्थक सक्रिय रूप से कई API फेंकता है NullPointerException।
उदाहरण के लिए, Map.containsKeyराज्यों के लिए Javadoc :
@ नल NullPointerException यदि कुंजी शून्य है और यह मानचित्र शून्य कुंजियों (वैकल्पिक) की अनुमति नहीं देता है।
यह आपके अपने NPE को फेंकने के लिए पूरी तरह से वैध है। सम्मेलन में पैरामीटर नाम को शामिल करना है जो अपवाद के संदेश में शून्य था।
पैटर्न जाता है:
public void someMethod(Object mustNotBeNull) {
if (mustNotBeNull == null) {
throw new NullPointerException("mustNotBeNull must not be null");
}
}जो कुछ भी आप करते हैं, एक खराब मान को सेट होने और बाद में एक अपवाद को फेंकने की अनुमति न दें जब अन्य कोड इसका उपयोग करने का प्रयास करता है। यह एक बुरा सपना डिबगिंग बनाता है। आपको हमेशा "असफल-तेज" सिद्धांत का पालन करना चाहिए।
जेसन कोहेन के तर्क को वोट दिया क्योंकि यह अच्छी तरह से प्रस्तुत किया गया था। मुझे इसे चरण दर चरण विघटित करना है। ;-)
एनपीई JavaDoc स्पष्ट रूप से कहते हैं, "शून्य वस्तु की अन्य अवैध उपयोग करता है" । अगर यह सिर्फ उन स्थितियों तक सीमित था जहां रनटाइम एक शून्य का सामना करता है, तो ऐसा नहीं होना चाहिए, ऐसे सभी मामलों को अधिक स्पष्ट रूप से परिभाषित किया जा सकता है।
यदि आप गलत बात मान लेते हैं, तो यह मदद नहीं कर सकता है, लेकिन यह मानते हुए कि एनकैप्सुलेशन ठीक से लागू होता है, आपको वास्तव में परवाह या ध्यान नहीं देना चाहिए कि क्या एक अनुचित तरीके से शून्य का उल्लेख किया गया है या नहीं, क्या एक विधि ने अनुचित अशक्त का पता लगाया है और एक अपवाद को बंद कर दिया है।
मैं कई कारणों से IAE पर NPE का चयन करूंगा
दरअसल, अन्य अमान्य तर्कों के परिणामस्वरूप सभी प्रकार के अन्य अपवाद हो सकते हैं। UnknownHostException , FileNotFoundException , सिंटेक्स त्रुटि अपवाद की एक किस्म IndexOutOfBoundsException , प्रमाणीकरण विफलताएं, आदि, आदि
सामान्य तौर पर, मुझे लगता है कि एनपीई बहुत खराब है क्योंकि पारंपरिक रूप से कोड के साथ जुड़ा हुआ है जो असफल फास्ट सिद्धांत का पालन करने में विफल रहता है । इसके अलावा, JPEK की विफलता एक संदेश स्ट्रिंग के साथ NPE को आबाद करने में विफलता ने वास्तव में एक मजबूत नकारात्मक भावना पैदा की है जो अच्छी तरह से स्थापित नहीं है। दरअसल, एनपीई और आईएई के बीच एक रनटाइम परिप्रेक्ष्य से अंतर कड़ाई से नाम है। उस दृष्टिकोण से, आप नाम के साथ जितने सटीक होंगे, आप कॉलर को उतनी अधिक स्पष्टता देंगे।
यह एक "पवित्र युद्ध" शैली का प्रश्न है। दूसरे शब्दों में, दोनों विकल्प अच्छे हैं, लेकिन लोगों की अपनी प्राथमिकताएं होंगी जो वे मौत का बचाव करेंगे।
NullPointerExceptionइसे फेंक दिया जाना चाहिए: यह सम्मेलन है जिसे JDK उपयोग करता है, और इंटरफेस के लिए आवश्यकता होती है, यह अधिक विशिष्ट है (बस की तरह IndexOutOfBoundsException, आदि), आदि
यदि यह एक setterविधि है और nullइसे पारित किया जा रहा है, तो मुझे लगता है कि इसे फेंकने के लिए अधिक समझ होगी IllegalArgumentException। ए NullPointerExceptionउस मामले में अधिक समझ में आता है जहां आप वास्तव में उपयोग करने का प्रयास कर रहे हैं null।
इसलिए, यदि आप इसे का उपयोग कर रहे हैं और यह है null, NullPointer। उस में पारित किया जा रहा है, तो यह और है null, IllegalArgument।
अपाचे कॉमन्स लैंग में एक NullArgumentException है, जो यहां चर्चा की गई कई चीजों को करती है: यह IllegalArgumentException का विस्तार करती है और इसका एकमात्र निर्माता तर्क का नाम लेता है जो गैर-अशक्त होना चाहिए था।
जबकि मुझे लगता है कि NullArgumentException या IllegalArgumentException जैसी किसी चीज़ को फेंकना असाधारण परिस्थितियों का सही-सही वर्णन करता है, मेरे सहयोगियों और मैंने इस विषय पर बलोच की सलाह को मानने के लिए चुना है।
जो कहा जा रहा है उससे अधिक सहमत नहीं हो सकता। जल्दी असफल होना, तेजी से असफल होना। बहुत अच्छा अपवाद मंत्र।
प्रश्न जिसके बारे में अपवाद को फेंकना है वह ज्यादातर व्यक्तिगत स्वाद का मामला है। मेरे दिमाग में IllegalArgumentException NPE का उपयोग करने की तुलना में अधिक विशिष्ट लगती है क्योंकि यह मुझे बता रही है कि समस्या एक तर्क के साथ थी जो मैंने विधि से पारित की थी और उस मूल्य के साथ नहीं जो विधि का प्रदर्शन करते समय उत्पन्न हुई हो।
मेरे 2 सेंट
वास्तव में, अवैध गैर-प्रतिवाद अपवाद या NullPointerException को फेंकने का प्रश्न मेरे विनम्र दृष्टिकोण में है केवल जावा में अपवाद हैंडलिंग की एक अधूरी समझ के साथ अल्पसंख्यक के लिए "पवित्र युद्ध"। सामान्य तौर पर, नियम सरल हैं, और निम्नानुसार हैं:
IllegalArgumentException में सभी प्रकार के तर्क अवरोधों के उल्लंघन के मामले में कम से कम तीन बहुत अच्छे कारण हैं, तीसरे के साथ शायद इतना गंभीर है कि अभ्यास की खराब शैली को चिह्नित करें:
(1) एक प्रोग्रामर सुरक्षित रूप से यह नहीं मान सकता है कि तर्कों के उल्लंघन के सभी मामलों का परिणाम अवैध रूप से होता है, क्योंकि मानक वर्गों के बड़े बहुमत इस अपवाद का उपयोग करते हैं, बल्कि एक अपशिष्ट पदार्थ के रूप में यदि कोई विशेष प्रकार का अपवाद उपलब्ध नहीं है। अपने API में IllegalArgumentException में तर्क अवरोध उल्लंघन के सभी मामलों को मैप करने की कोशिश करने से केवल आपकी कक्षाओं का उपयोग करने वाले प्रोग्रामर को निराशा होती है, क्योंकि मानक पुस्तकालय ज्यादातर आपके द्वारा उल्लंघन करने वाले विभिन्न नियमों का पालन करते हैं, और आपके अधिकांश एपीआई उपयोगकर्ता उनका भी उपयोग करेंगे!
(2) अपवादों का मानचित्रण वास्तव में एक अलग तरह की विसंगति के परिणामस्वरूप होता है, जो एकल वंशानुक्रम के कारण होता है: सभी जावा अपवाद वर्ग होते हैं, और इसलिए केवल एकल वंशानुक्रम का समर्थन करते हैं। इसलिए, अपवाद बनाने का कोई तरीका नहीं है जो सही मायने में NullPointerException और IllegalArgumentException दोनों को कहते हैं, क्योंकि उपवर्ग केवल एक या दूसरे से विरासत में मिल सकते हैं। एक अशक्त तर्क के मामले में एक अवैध तर्क को फेंकना इसलिए एपीआई उपयोगकर्ताओं के लिए समस्याओं के बीच अंतर करना कठिन बना देता है जब भी कोई प्रोग्राम प्रोग्राम को समस्या को सही करने की कोशिश करता है, उदाहरण के लिए कॉल वैल्यू में डिफ़ॉल्ट मान खिलाकर!
(3) मानचित्रण वास्तव में बग मास्किंग का खतरा पैदा करता है: IllegalArgumentException में तर्क अवरोध उल्लंघन को मैप करने के लिए, आपको किसी भी विवश तर्क देने वाले प्रत्येक तरीके के भीतर एक बाहरी कोशिश को पकड़ने की आवश्यकता होगी। हालाँकि, बस इस कैच ब्लॉक में RuntimeException को पकड़ना सवाल से बाहर है, क्योंकि जोखिमों को मैप करने वाले RuntimeException को आपके भीतर इस्तेमाल की गई स्वतंत्र विधियों द्वारा अवैध तरीके से फेंक दिया गया है, भले ही वे तर्क अवरोध उल्लंघन के कारण न हों। इसलिए आपको बहुत विशिष्ट होने की आवश्यकता है, लेकिन यहां तक कि यह प्रयास आपको उस मामले से भी बचाता नहीं है, जब आप गलती से किसी अन्य एपीआई (यानी एक बग) के अनजाने क्रमांक अपवाद को अपने एपीआई के एक अवैध तरीके से अपवाद में मैप करते हैं।
दूसरी ओर मानक अभ्यास के साथ, नियम सरल रहते हैं, और अपवाद के कारण अप्रकाशित और विशिष्ट रहते हैं। मेथड कॉलर के लिए, नियम आसान भी हैं: - यदि आप किसी भी प्रकार के डॉक्यूमेंटेड रनटाइम अपवाद का सामना करते हैं, क्योंकि आपने एक अवैध मूल्य पारित किया है, या तो कॉल को डिफ़ॉल्ट रूप से दोहराएं (इस विशिष्ट अपवादों के लिए यह आवश्यक है), या अपना कोड सही करें - अगर दूसरी तरफ आप एक रनटाइम अपवाद का सामना करते हैं जो किसी दिए गए तर्क के लिए होने के लिए दस्तावेज नहीं है, तो विधि के निर्माताओं को एक बग रिपोर्ट दर्ज करें ताकि यह सुनिश्चित हो सके कि या तो उनका कोड या उनका दस्तावेज तय हो गया है।
यदि कोई पैरामीटर अमान्य घोषित करने और जितना संभव हो उतना विवरण देने के लिए IllegalArgumentException (स्ट्रिंग संदेश) का उपयोग करने के लिए स्वीकृत अभ्यास ... तो यह कहने के लिए कि मापदंडों को अशक्त पाया गया था जबकि गैर-अशक्त, आप कुछ करेंगे। इस तरह:
if( variable == null )
throw new IllegalArgumentException("The object 'variable' cannot be null");आपके पास वस्तुतः "NullPointerException" का उपयोग करने का कोई कारण नहीं है। NullPointerException जावा वर्चुअल मशीन द्वारा फेंका गया एक अपवाद है जब आप null संदर्भ (जैसे toString () ) पर कोड निष्पादित करने का प्रयास करते हैं ।
एक अपवाद को फेंकना जो nullतर्कों के लिए अनन्य है (चाहे NullPointerExceptionया कस्टम प्रकार) स्वचालित nullपरीक्षण को अधिक विश्वसनीय बनाता है । यह स्वचालित परीक्षण प्रतिबिंब और मूलभूत मूल्यों का एक सेट के साथ किया जा सकता है, के रूप में अमरूद की NullPointerTester। उदाहरण के लिए, NullPointerTesterनिम्न विधि को कॉल करने का प्रयास करेंगे ...
Foo(String string, List<?> list) {
checkArgument(string.length() > 0);
// missing null check for list!
this.string = string;
this.list = list;
}... तर्कों की दो सूचियों के साथ: "", nullऔर null, ImmutableList.of()। यह परीक्षण करेगा कि इनमें से प्रत्येक कॉल अपेक्षित है NullPointerException। इस कार्यान्वयन के लिए, एक nullसूची पास करने से उत्पादन नहीं होता है NullPointerException। हालाँकि, यह ऐसा करने के लिए होता है IllegalArgumentExceptionक्योंकि NullPointerTesterडिफ़ॉल्ट स्ट्रिंग का उपयोग करने के लिए होता है ""। यदि NullPointerTesterकेवल मूल्यों के NullPointerExceptionलिए उम्मीद है null, तो यह बग को पकड़ता है। अगर यह उम्मीद करता है IllegalArgumentException, तो यह याद आती है।
कुछ संग्रह मान लेते हैं कि nullउपयोग करने के NullPointerExceptionबजाय अस्वीकार कर दिया गया है IllegalArgumentException। उदाहरण के लिए, यदि आप किसी ऐसे सेट से तुलना करते हैं nullजो अस्वीकार करता है null, तो पहला सेट containsAllदूसरे पर कॉल करेगा और उसे पकड़ लेगा NullPointerException- लेकिन नहीं IllegalArgumentException। (मैं के कार्यान्वयन को देख रहा हूँ AbstractSet.equals।)
आप यथोचित तर्क दे सकते हैं कि इस तरह से अनियंत्रित अपवादों का उपयोग करना एक एंटीपैटर्न है, जो संग्रह की तुलना ऐसे संग्रह से करते हैं जिनमें शामिल nullनहीं हो सकता nullहै, एक संभावना बग है जो वास्तव में एक अपवाद का उत्पादन करना चाहिए , या जो nullएक संग्रह में रखना एक बुरा विचार है। । फिर भी, जब तक आप यह कहने के लिए तैयार नहीं हैं कि equalsइस तरह के मामले में एक अपवाद फेंक देना चाहिए, आप याद कर रहे हैं कि NullPointerExceptionकुछ परिस्थितियों में आवश्यक है लेकिन दूसरों में नहीं। ("IAE से पहले NPE को छोड़कर 'c' ...")
new TreeSet<>().containsAll(Arrays.asList((Object) null));फेंकता है NPEक्योंकि Listहोता है null।
एक व्यक्तिपरक प्रश्न के रूप में इसे बंद किया जाना चाहिए, लेकिन जैसा कि यह अभी भी खुला है:
यह मेरे रोजगार के पिछले स्थान पर इस्तेमाल की जाने वाली आंतरिक नीति का हिस्सा है और इसने वास्तव में अच्छा काम किया है। यह सब स्मृति से है इसलिए मैं सटीक शब्द याद नहीं रख सकता। यह ध्यान देने योग्य है कि उन्होंने चेक किए गए अपवादों का उपयोग नहीं किया, लेकिन यह प्रश्न के दायरे से परे है। अनियंत्रित अपवादों का उपयोग उन्होंने 3 मुख्य श्रेणियों में किया।
NullPointerException: जानबूझकर न फेंके। NPE को केवल VM द्वारा फेंका जाना है, जब एक अशक्त संदर्भ को dereferencing करते हैं। यह सुनिश्चित करने के लिए सभी संभव प्रयास किए जाते हैं कि इन्हें कभी फेंका न जाए। इन त्रुटियों को खोजने के लिए कोड विश्लेषण उपकरण के साथ संयोजन में @Nullable और @NotNull का उपयोग किया जाना चाहिए।
IllegalArgumentException: जब किसी फ़ंक्शन का तर्क सार्वजनिक दस्तावेज़ के अनुरूप नहीं होता है, तो उसे फेंक दें, ताकि त्रुटि की पहचान की जा सके और पास किए गए तर्कों के संदर्भ में वर्णन किया जा सके। ओपी की स्थिति इस श्रेणी में आ जाएगी।
IllegalStateException: जब किसी फ़ंक्शन को कॉल किया जाता है, तो फेंका जाता है और इसके तर्क या तो उस समय अनपेक्षित होते हैं, जब वे पास होते हैं या ऑब्जेक्ट की स्थिति के साथ असंगत होते हैं, जिस विधि का एक सदस्य होता है।
उदाहरण के लिए, जिन चीजों की लंबाई थी, उनमें IndexOutOfBoundsException के दो आंतरिक संस्करण थे। यदि कोई अनुक्रमणिका लंबाई से बड़ी थी, तो उसका उपयोग अवैध श्रेणी के एक उप-वर्ग में किया जाता है। यदि सूचकांक नकारात्मक था, तो अन्य गैरकानूनी तरीके से अवैध तरीके से इस्तेमाल किया जा सकता है। ऐसा इसलिए था क्योंकि आप ऑब्जेक्ट में अधिक आइटम जोड़ सकते हैं और तर्क मान्य होगा, जबकि एक नकारात्मक संख्या कभी मान्य नहीं होती है।
जैसा कि मैंने कहा, यह प्रणाली वास्तव में अच्छी तरह से काम करती है, और यह किसी को यह समझाने के लिए ले गई कि भेद क्यों है: "त्रुटि के प्रकार के आधार पर यह आपके लिए काफी सीधा है कि आपको क्या करना है। यहां तक कि अगर आप वास्तव में आंकड़ा नहीं कर सकते हैं। क्या गलत हुआ, आप यह पता लगा सकते हैं कि उस त्रुटि को पकड़ने के लिए और अतिरिक्त डिबगिंग जानकारी कहां से बनाई जाए। "
NullPointerException: Null केस को हैंडल करें या एक जोर में डालें ताकि NPE फेंके नहीं। यदि आप एक जोर में डाल दो अन्य प्रकारों में से सिर्फ एक है। यदि संभव हो, तो डीबग करना जारी रखें जैसे कि दावा पहले स्थान पर था।
IllegalArgumentException: आपकी कॉल साइट पर कुछ गलत है। यदि पास किए जा रहे मान किसी अन्य फ़ंक्शन से हैं, तो पता करें कि आपको गलत मान क्यों मिल रहा है। यदि आप अपने किसी तर्क में गुजर रहे हैं तो कॉल स्टैक तक त्रुटि जांच का प्रचार करें जब तक कि आपको वह फ़ंक्शन न मिल जाए जो आपको उम्मीद नहीं है।
IllegalStateException: आपने अपने कार्यों को सही क्रम में नहीं बुलाया है। यदि आप अपने किसी तर्क का उपयोग कर रहे हैं, तो उन्हें जाँचें और समस्या का वर्णन करते हुए एक IllegalArgumentException को फेंक दें। आप तब तक स्टेक के खिलाफ गाल को प्रचारित कर सकते हैं जब तक कि आप समस्या का पता नहीं लगाते।
वैसे भी, उनका कहना यह था कि आप केवल ढेर की नकल कर सकते हैं। आपके पास IllegalStateException या NullPointerException को स्टैक तक प्रचारित करने का कोई तरीका नहीं है क्योंकि उनके पास आपके फ़ंक्शन के साथ कुछ करना था।
सामान्य तौर पर, एक डेवलपर को NullPointerException को कभी नहीं फेंकना चाहिए । यह अपवाद रनटाइम द्वारा फेंका जाता है जब कोड एक चर को रोकने के लिए प्रयास करता है जिसका मूल्य शून्य है। इसलिए, यदि आपका तरीका स्पष्ट रूप से अशक्त करना चाहता है, जैसा कि केवल एक अशक्त मान होने के विरोध में एक NullPointerException को बढ़ाता है, तो आपको एक IllegalArgumentException को फेंक देना चाहिए।
मैं अन्य गैरकानूनी तर्कों से नल की दलीलों को जानना चाहता था, इसलिए मैंने IA से एक अपवाद प्राप्त किया जिसका नाम NullArgumentException था। अपवाद संदेश को पढ़ने की आवश्यकता के बिना, मुझे पता है कि एक अशक्त तर्क को एक विधि में पारित किया गया था और संदेश को पढ़ने से मुझे पता चलता है कि कौन सा तर्क अशक्त था। मैं अभी भी IAE हैंडलर के साथ NullArgumentException को पकड़ता हूं, लेकिन मेरे लॉग में वह जगह है जहां मैं अंतर को जल्दी से देख सकता हूं।
द विक्टोटॉमी ... क्या वे गैर-अतिव्यापी हैं? पूरे के केवल गैर-अतिव्यापी हिस्से एक द्विभाजन बना सकते हैं। जैसा की मैं देख पा रहा हूँ:
throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));NullPointerExceptionकुछ नहीं होगा। केवल एक चीज जो मदद कर सकती है IllegalNullPointerArgumentException extends IllegalArgumentException, NullPointerException, लेकिन हमारे पास कोई बहु विरासत नहीं है।
NullPointerExceptionकिसी वस्तु को उस संदर्भ चर के साथ एक्सेस करने का प्रयास करते समय जिसका वर्तमान मूल्य है null।
IllegalArgumentException फेंक दिया जाता है जब एक विधि एक तर्क प्राप्त करती है जो विधि की अपेक्षा अलग होती है।
आदर्श रूप से रनटाइम अपवाद नहीं फेंका जाना चाहिए। आपके परिदृश्य के लिए एक जाँच अपवाद (व्यावसायिक अपवाद) बनाया जाना चाहिए। क्योंकि यदि इनमें से कोई भी अपवाद फेंका और लॉग किया गया है, तो यह लॉग्स से गुजरते समय डेवलपर को गुमराह करता है। इसके बजाय व्यावसायिक अपवाद उस दहशत का निर्माण नहीं करते हैं और आमतौर पर लॉग को समस्या निवारण करते समय अनदेखा किया जाता है।
ऊपर दिए गए दो अपवादों की कड़ियों से लेकर परिभाषाएँ हैं: गैर कानूनी मान्यता: यह इंगित करने के लिए कि एक विधि को अवैध या अनुचित तर्क दिया गया है। NullPointerException: जब कोई एप्लिकेशन किसी ऑब्जेक्ट की आवश्यकता होती है, उस स्थिति में नल का उपयोग करने का प्रयास करता है।
यहां बड़ा अंतर यह है कि IllegalArgumentException का उपयोग तब किया जाता है जब जाँच की जाती है कि विधि का तर्क मान्य है। NullPointerException का उपयोग माना जाता है जब भी कोई ऑब्जेक्ट शून्य होने पर "उपयोग" किया जाता है।
मुझे उम्मीद है कि दोनों को परिप्रेक्ष्य में रखने में मदद मिलेगी।
यदि यह एक "सेटर" है, या कहीं मुझे बाद में उपयोग करने के लिए एक सदस्य मिल रहा है, तो मैं IllegalArgumentException का उपयोग करता हूं।
यदि यह ऐसा कुछ है जिसका मैं अभी (विधिवत) उपयोग करने जा रहा हूं, तो मैं NullPointerException को सटीक रूप से फेंक देता हूं। मुझे रनटाइम करने से बेहतर यह पसंद है, क्योंकि मैं एक सहायक संदेश प्रदान कर सकता हूं (ऐसा लगता है कि रनटाइम ऐसा भी कर सकता है, लेकिन यह एक और दिन के लिए एक शेख़ी है)।
यदि मैं एक विधि को ओवरराइड कर रहा हूं, तो मैं ओवरराइड विधि का उपयोग करता हूं।
आपको एक IllegalArgumentException को फेंकना चाहिए, क्योंकि यह प्रोग्रामर को स्पष्ट कर देगा कि उसने कुछ अमान्य किया है। डेवलपर्स को VM द्वारा फेंके गए NPE को देखने के लिए उपयोग किया जाता है, ताकि किसी भी प्रोग्रामर को तुरंत अपनी त्रुटि का एहसास न हो, और बेतरतीब ढंग से चारों ओर देखना शुरू कर देगा, या इससे भी बदतर, 'छोटी गाड़ी' होने के लिए अपने कोड को दोष देगा।
इस मामले में, IllegalArgumentException आपके एपीआई का उपयोग करके उपयोगकर्ता को स्पष्ट जानकारी देती है कि "सुस्त नहीं होना चाहिए"। जैसा कि अन्य फ़ोरम उपयोगकर्ताओं ने बताया कि यदि आप अपनी API का उपयोग करके उपयोगकर्ता को सही जानकारी देना चाहते हैं तो आप NPE का उपयोग कर सकते हैं।
गैरीएफ और ट्विकट ने "प्रभावी जावा" (जिसे मैं शपथ लेता हूं) संदर्भों को गिरा दिया जो एनपीई का उपयोग करने की सिफारिश करता है। और यह देखते हुए कि कैसे अन्य अच्छे एपीआई का निर्माण किया जाता है, यह देखने का सबसे अच्छा तरीका है कि आपके एपीआई का निर्माण कैसे किया जाए।
वसंत एपीआई को देखने के लिए एक और अच्छा उदाहरण है। उदाहरण के लिए, org.springframework.beans.BeanUtils.instantiateClass (कंस्ट्रक्टर ctor, ऑब्जेक्ट [] args) में Assert.notNull (ctor, "कंस्ट्रक्टर को शून्य नहीं होना चाहिए") लाइन है। org.springframework.util.Assert.notNull (ऑब्जेक्ट ऑब्जेक्ट, स्ट्रिंग संदेश) विधि यह देखने के लिए जांचती है कि क्या तर्क (ऑब्जेक्ट) पास है या नहीं और यदि यह एक नया IllegalArguetException (संदेश) फेंकता है जो तब org में पकड़ा जाता है। springframework.beans.BeanUtils.instantiateClass (...) विधि।
यदि आप एक NPE फेंकना चुनते हैं और आप अपने तरीके में तर्क का उपयोग कर रहे हैं, तो यह निरर्थक और एक नल के लिए स्पष्ट रूप से जांचना महंगा हो सकता है। मुझे लगता है कि VM आपके लिए पहले से ही ऐसा कर रहा है।
NPEफिर भी IAEयदि वे चाहते हैं तो प्रोग्रामर VM के सामने बात करते हैं।