java - बचना!=शून्य बयान




object nullpointerexception (20)

अगर शून्य मूल्यों की अनुमति नहीं है

यदि आपकी विधि को बाहरी रूप से कहा जाता है, तो इस तरह से कुछ शुरू करें:

public void method(Object object) {
  if (object == null) {
    throw new IllegalArgumentException("...");
  }

फिर, उस विधि के बाकी हिस्सों में, आपको पता चलेगा कि object शून्य नहीं है।

यदि यह एक आंतरिक विधि है (एपीआई का हिस्सा नहीं है), बस दस्तावेज है कि यह शून्य नहीं हो सकता है, और यही वह है।

उदाहरण:

public String getFirst3Chars(String text) {
  return text.subString(0, 3);
}

हालांकि, अगर आपकी विधि सिर्फ मूल्य को पास करती है, और अगली विधि इसे आदि पर पास करती है तो यह समस्याग्रस्त हो सकती है। उस स्थिति में आप ऊपर के रूप में तर्क की जांच कर सकते हैं।

अगर शून्य की अनुमति है

यह वास्तव में निर्भर करता है। अगर मुझे लगता है कि मैं अक्सर ऐसा कुछ करता हूं:

if (object == null) {
  // something
} else {
  // something else
}

तो मैं शाखा, और दो पूरी तरह से अलग चीजें करते हैं। कोई बदसूरत कोड स्निपेट नहीं है, क्योंकि मुझे डेटा के आधार पर दो अलग-अलग चीजों को करने की ज़रूरत है। उदाहरण के लिए, क्या मुझे इनपुट पर काम करना चाहिए, या क्या मुझे एक अच्छा डिफ़ॉल्ट मान की गणना करनी चाहिए?

वास्तव में मेरे लिए मुहावरे का उपयोग करना दुर्लभ है " if (object != null && ... "।

यदि आप उदाहरणों को दिखाते हैं कि आप आम तौर पर मुहावरे का उपयोग करते हैं तो उदाहरण आपको उदाहरण देना आसान हो सकता है।

मैं object != null उपयोग करता हूं object != null NullPointerException से बचने के लिए बहुत कुछ नहीं।

क्या इसका कोई अच्छा विकल्प है?

उदाहरण के लिए:

if (someobject != null) {
    someobject.doCalc();
}

यह एक NullPointerException से बचाता है, जब यह अज्ञात है यदि ऑब्जेक्ट null या नहीं।

ध्यान दें कि स्वीकृत उत्तर पुराना हो सकता है, अधिक हालिया दृष्टिकोण के लिए https://stackoverflow.com/a/2386013/12943 देखें।


यदि अपरिभाषित मानों की अनुमति नहीं है:

संभावित नल dereferencing के बारे में आपको चेतावनी देने के लिए आप अपने आईडीई को कॉन्फ़िगर कर सकते हैं। ग्रहण में, प्राथमिकताएं> जावा> कंपाइलर> त्रुटियां / चेतावनी / शून्य विश्लेषण देखें

यदि अपरिभाषित मानों की अनुमति है:

यदि आप एक नया एपीआई परिभाषित करना चाहते हैं जहां अपरिभाषित मान समझ में आते हैं , तो विकल्प पैटर्न का उपयोग करें (कार्यात्मक भाषाओं से परिचित हो सकता है)। इसके निम्नलिखित फायदे हैं:

  • यह स्पष्ट रूप से एपीआई में कहा गया है कि कोई इनपुट या आउटपुट मौजूद है या नहीं।
  • कंपाइलर आपको "अपरिभाषित" केस को संभालने के लिए मजबूर करता है।
  • विकल्प एक मोनैड है , इसलिए वर्बोज़ नल जांच की कोई आवश्यकता नहीं है, केवल मूल्य (example) सुरक्षित) का उपयोग करने के लिए मानचित्र / foreach / getOrElse या एक समान संयोजक का उपयोग करें।

जावा 8 में एक अंतर्निहित Optional वर्ग है (अनुशंसित); पिछले संस्करणों के लिए, पुस्तकालय विकल्प हैं, उदाहरण के लिए Guava के Optional या FunctionalJava Guava Option । लेकिन जावा में विकल्प (यहां तक ​​कि 8) का उपयोग करके कई कार्यात्मक-शैली पैटर्न की तरह, कुछ बॉयलरप्लेट में परिणाम होते हैं, जिन्हें आप कम वर्बोज़ जेवीएम भाषा, जैसे स्कैला या एक्सटेन्ड का उपयोग करके कम कर सकते हैं।

यदि आपको एक एपीआई से निपटना है जो नल वापस कर सकता है , तो आप जावा में ज्यादा कुछ नहीं कर सकते हैं। Xtend और Groovy एल्विस ऑपरेटर है ?: और शून्य-सुरक्षित dereference ऑपरेटर ?. , लेकिन ध्यान दें कि यह शून्य संदर्भ के मामले में शून्य हो जाता है, इसलिए यह शून्य के उचित संचालन को "स्थगित" करता है।


Google संग्रह ढांचा शून्य जांच प्राप्त करने के लिए एक अच्छा और सुरुचिपूर्ण तरीका प्रदान करता है।

इस तरह पुस्तकालय वर्ग में एक विधि है:

static <T> T checkNotNull(T e) {
   if (e == null) {
      throw new NullPointerException();
   }
   return e;
}

और उपयोग है ( import static साथ):

...
void foo(int a, Person p) {
   if (checkNotNull(p).getAge() > a) {
      ...
   }
   else {
      ...
   }
}
...

या आपके उदाहरण में:

checkNotNull(someobject).doCalc();

आप किस प्रकार की ऑब्जेक्ट्स की जांच कर रहे हैं, इस पर निर्भर करते हुए आप अपाचे कॉमन्स में कुछ कक्षाओं का उपयोग करने में सक्षम हो सकते हैं जैसे: apache commons lang और apache commons संग्रह

उदाहरण:

String foo;
...
if( StringUtils.isBlank( foo ) ) {
   ///do something
}

या (आपको जो जांचने की आवश्यकता है उसके आधार पर):

String foo;
...
if( StringUtils.isEmpty( foo ) ) {
   ///do something
}

स्ट्रिंगउल्ट्स क्लास केवल कई में से एक है; उन कॉमन्स में बहुत अच्छी कक्षाएं हैं जो शून्य सुरक्षित हेरफेर करते हैं।

जब आप अपाचे लाइब्रेरी (कॉमन्स-लैंग-2.4.jar) शामिल करते हैं तो आप जावा में शून्य वर्लीकरण का उपयोग कैसे कर सकते हैं इसका एक उदाहरण यहां दिया गया है।

public DOCUMENT read(String xml, ValidationEventHandler validationEventHandler) {
    Validate.notNull(validationEventHandler,"ValidationHandler not Injected");
    return read(new StringReader(xml), true, validationEventHandler);
}

और यदि आप वसंत का उपयोग कर रहे हैं, तो वसंत में भी इसके पैकेज में समान कार्यक्षमता है, लाइब्रेरी देखें (वसंत-2.4.6.jar)

वसंत से इस स्थिर वर्ग का उपयोग करने के तरीके पर उदाहरण (org.springframework.util.Assert)

Assert.notNull(validationEventHandler,"ValidationHandler not Injected");

केवल इस स्थिति के लिए -

एक बराबर विधि का आह्वान करने से पहले एक चर शून्य है या नहीं, यह जांच नहीं कर रहा है (एक स्ट्रिंग नीचे उदाहरण की तुलना करें):

if ( foo.equals("bar") ) {
 // ...
}

अगर foo मौजूद नहीं है तो परिणामस्वरूप NullPointerException होगा।

यदि आप अपनी String तुलना इस तरह करते हैं तो आप इससे बच सकते हैं:

if ( "bar".equals(foo) ) {
 // ...
}

जावा 8 के साथ नया java.util.Optional क्लास आता है जो तर्कसंगत रूप से कुछ समस्या हल करता है। कोई कम से कम कह सकता है कि यह कोड की पठनीयता में सुधार करता है, और सार्वजनिक एपीआई के मामले में एपीआई का अनुबंध ग्राहक डेवलपर को स्पष्ट करता है।

वे इस तरह काम करते हैं:

किसी दिए गए प्रकार ( Fruit ) के लिए एक वैकल्पिक वस्तु एक विधि के रिटर्न प्रकार के रूप में बनाई गई है। यह खाली हो सकता है या एक Fruit वस्तु हो सकती है:

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for (Fruit fruit : fruits) {
      if (fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

अब इस कोड को देखें जहां हम fruits दिए गए फल उदाहरण के लिए Fruit ( fruits ) की एक सूची खोजते हैं:

Optional<Fruit> found = find("lemon", fruits);
if (found.isPresent()) {
   Fruit fruit = found.get();
   String name = fruit.getName();
}

आप map() ऑपरेटर का उपयोग गणना करने के लिए - या एक वैकल्पिक ऑब्जेक्ट से एक मान निकालने के लिए कर सकते हैं। orElse() आपको अनुपलब्ध मानों के लिए फ़ॉलबैक प्रदान करने देता है।

String nameOrNull = find("lemon", fruits)
    .map(f -> f.getName())
    .orElse("empty-name");

बेशक, शून्य / खाली मूल्य की जांच अभी भी जरूरी है, लेकिन कम से कम डेवलपर को पता है कि मूल्य खाली हो सकता है और जांच को भूलने का जोखिम सीमित है।

जब भी कोई रिटर्न वैल्यू रिक्त हो, Optional का उपयोग करके स्क्रैच से बनाया गया एपीआई में, और केवल सादा ऑब्जेक्ट लौटाते समय जब यह null (सम्मेलन) नहीं हो सकता है, तो क्लाइंट कोड सरल ऑब्जेक्ट रिटर्न वैल्यू पर शून्य चेक छोड़ सकता है ...

बेशक Optional विधि को विधि तर्क के रूप में भी इस्तेमाल किया जा सकता है, शायद कुछ मामलों में 5 या 10 अधिभार विधियों से वैकल्पिक तर्कों को इंगित करने का एक बेहतर तरीका।

Optional अन्य सुविधाजनक तरीकों की पेशकश करता है, जैसे कि orElse जो डिफ़ॉल्ट मान के उपयोग की अनुमति देता है, और ifPresent जो लैम्ब्डा अभिव्यक्तियों के साथ काम करता है।

मैं आपको इस आलेख को पढ़ने के लिए आमंत्रित करता हूं (इस उत्तर को लिखने के लिए मेरा मुख्य स्रोत) जिसमें NullPointerException (और सामान्य शून्य सूचक में) समस्याग्रस्त और साथ ही साथ (आंशिक) समाधान Optional द्वारा लाया गया है: जावा वैकल्पिक ऑब्जेक्ट्स


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


यदि आप जेटब्रेन इंटेलिजे आईडीईए , ग्रहण या नेटबीन्स या खोजबग जैसे टूल जैसे जावा आईडीई का उपयोग करते हैं (या उपयोग करने की योजना बनाते हैं तो आप इस समस्या को हल करने के लिए एनोटेशन का उपयोग कर सकते हैं।

असल में, आपको @Nullable और @Nullable मिल गया है।

आप विधि और पैरामीटर में इस तरह उपयोग कर सकते हैं:

@NotNull public static String helloWorld() {
    return "Hello World";
}

या

@Nullable public static String helloWorld() {
    return "Hello World";
}

दूसरा उदाहरण संकलित नहीं होगा (इंटेलिजे आईडीईए में)।

जब आप कोड के दूसरे भाग में पहले helloWorld() फ़ंक्शन का उपयोग करते हैं:

public static void main(String[] args)
{
    String result = helloWorld();
    if(result != null) {
        System.out.println(result);
    }
}

अब इंटेलिजे आईडीईए कंपाइलर आपको बताएगा कि चेक बेकार है, क्योंकि helloWorld() फ़ंक्शन null वापस नहीं लौटाएगा।

पैरामीटर का उपयोग करना

void someMethod(@NotNull someParameter) { }

यदि आप कुछ लिखते हैं:

someMethod(null);

यह संकलित नहीं होगा।

@Nullable का उपयोग कर अंतिम उदाहरण

@Nullable iWantToDestroyEverything() { return null; }

यह कर रहा हूं

iWantToDestroyEverything().something();

और आप सुनिश्चित हो सकते हैं कि ऐसा नहीं होगा। :)

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

IntelliJ IDEA 10.5 और बाद में, उन्होंने किसी भी अन्य @Nullable कार्यान्वयन के लिए समर्थन जोड़ा।

ब्लॉग पोस्ट देखें अधिक लचीला और कॉन्फ़िगर करने योग्य @ Nullable / @ NotNull एनोटेशन


वाह, जब हम NullObject pattern की सिफारिश करने के 57 अलग-अलग तरीके हैं, तो मुझे लगभग एक और जवाब जोड़ने से नफरत है, लेकिन मुझे लगता है कि इस प्रश्न में रुचि रखने वाले कुछ लोग यह जानना चाहेंगे कि जावा 7 के लिए टेबल पर एक प्रस्ताव है "शून्य -साफ हैंडलिंग " - एक सुव्यवस्थित वाक्यविन्यास अगर-बराबर-शून्य तर्क के लिए।

एलेक्स मिलर द्वारा दिया गया उदाहरण इस तरह दिखता है:

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}  

?. इसका मतलब है कि बाएं पहचानकर्ता को केवल संदर्भित करें यदि यह शून्य नहीं है, अन्यथा अभिव्यक्ति के शेष को null रूप में मूल्यांकन करें। कुछ लोग, जैसे कि जावा पॉस सदस्य डिक वॉल और देवॉक्सक्स के मतदाता वास्तव में इस प्रस्ताव से प्यार करते हैं, लेकिन इस आधार पर विपक्ष भी है कि यह वास्तव में एक भावनात्मक मूल्य के रूप में null अधिक उपयोग को प्रोत्साहित करेगा।

अद्यतन: जावा 7 में एक नल-सुरक्षित ऑपरेटर के लिए एक proposed परियोजना सिक्का के तहत प्रस्तुत किया गया है वाक्यविन्यास ऊपर दिए गए उदाहरण से थोड़ा अलग है, लेकिन यह वही धारणा है।

अद्यतन: शून्य-सुरक्षित ऑपरेटर प्रस्ताव ने इसे परियोजना सिक्का में नहीं बनाया है। तो, आप जावा 7 में यह वाक्यविन्यास नहीं देख पाएंगे।


अधिकांश डेवलपर्स के लिए यह सबसे आम त्रुटि हुई है।

हमारे पास इसे संभालने के कई तरीके हैं।

दृष्टिकोण 1:

org.apache.commons.lang.Validate //using apache framework

नहीं शून्य (ऑब्जेक्ट ऑब्जेक्ट, स्ट्रिंग संदेश)

दृष्टिकोण 2:

if(someObject!=null){ // simply checking against null
}

दृष्टिकोण 3:

@isNull @Nullable  // using annotation based validation

दृष्टिकोण 4:

// by writing static method and calling it across whereever we needed to check the validation

static <T> T isNull(someObject e){  
   if(e == null){
      throw new NullPointerException();
   }
   return e;
}

क्या मैं इसे अधिक आम तौर पर उत्तर दे सकता हूं!

हम आम तौर पर इस मुद्दे का सामना करते हैं जब विधियों को हमारे द्वारा अपेक्षित तरीके से पैरामीटर प्राप्त नहीं होते हैं (खराब विधि कॉल प्रोग्रामर की गलती है)। उदाहरण के लिए: आप ऑब्जेक्ट प्राप्त करने की अपेक्षा करते हैं, इसके बजाय आपको शून्य मिलती है। आप कम से कम एक चरित्र के साथ एक स्ट्रिंग प्राप्त करने की उम्मीद करते हैं, इसके बजाय आपको खाली स्ट्रिंग मिलती है ...

तो इसमें कोई अंतर नहीं है:

if(object == null){
   //you called my method badly!

}

या

if(str.length() == 0){
   //you called my method badly again!
}

वे दोनों यह सुनिश्चित करना चाहते हैं कि हम किसी भी अन्य कार्य करने से पहले, वैध पैरामीटर प्राप्त करें।

जैसा कि कुछ अन्य उत्तरों में बताया गया है, उपरोक्त समस्याओं से बचने के लिए आप अनुबंध पैटर्न द्वारा डिजाइन का पालन कर सकते हैं । कृपया http://en.wikipedia.org/wiki/Design_by_contract देखें ।

जावा में इस पैटर्न को लागू करने के लिए, आप javax.annotation.NotNull जैसे मूल जावा एनोटेशन का उपयोग कर सकते हैं या हाइबरनेट वैलिडेटर जैसे अधिक परिष्कृत पुस्तकालयों का उपयोग कर सकते हैं ।

बस एक नमूना:

getCustomerAccounts(@NotEmpty String customerId,@Size(min = 1) String accountType)

अब आप इनपुट पैरामीटर की जांच किए बिना अपनी विधि के मूल कार्य को सुरक्षित रूप से विकसित कर सकते हैं, वे आपके तरीकों को अप्रत्याशित पैरामीटर से सुरक्षित रखते हैं।

आप एक कदम आगे जा सकते हैं और सुनिश्चित कर सकते हैं कि आपके आवेदन में केवल वैध pojos बनाया जा सके। (हाइबरनेट सत्यापनकर्ता साइट से नमूना)

public class Car {

   @NotNull
   private String manufacturer;

   @NotNull
   @Size(min = 2, max = 14)
   private String licensePlate;

   @Min(2)
   private int seatCount;

   // ...
}

वास्तव में जावा में आम "समस्या"।

सबसे पहले, इस पर मेरे विचार:

मैं मानता हूं कि जब कुछ पूर्ण हो गया था तो "खाने" के लिए बुरा होता है जहां न्यूल वैध मान नहीं है। यदि आप किसी प्रकार की त्रुटि के साथ विधि से बाहर नहीं निकल रहे हैं तो इसका मतलब है कि आपकी विधि में कुछ भी गलत नहीं हुआ जो सत्य नहीं है। तो आप शायद इस मामले में शून्य वापस लौटते हैं, और प्राप्त करने की विधि में आप फिर से शून्य की जांच करते हैं, और यह कभी समाप्त नहीं होता है, और आप "if! = Null", आदि के साथ समाप्त होते हैं ..

इसलिए, आईएमएचओ, शून्य एक महत्वपूर्ण त्रुटि होनी चाहिए जो आगे निष्पादन को रोकती है (यानी, जहां शून्य मान्य मान नहीं है)।

जिस तरह से मैं इस समस्या को हल करता हूं यह है:

सबसे पहले, मैं इस सम्मेलन का पालन करता हूं:

  1. सभी सार्वजनिक तरीकों / एपीआई हमेशा अपने तर्कों को शून्य के लिए जांचते हैं
  2. सभी निजी विधियां शून्य के लिए जांच नहीं करती हैं क्योंकि वे नियंत्रित विधियां हैं (अगर इसे उपरोक्त नहीं किया गया है तो बस नलपोइंटर अपवाद के साथ मरने दें)
  3. एकमात्र अन्य विधियां जो शून्य के लिए जांच नहीं करती हैं वे उपयोगिता विधियां हैं। वे सार्वजनिक हैं, लेकिन यदि आप उन्हें किसी कारण से बुलाते हैं, तो आप जानते हैं कि आप कौन से पैरामीटर पास करते हैं। यह पानी प्रदान किए बिना केतली में पानी उबालने की कोशिश की तरह है ...

और अंत में, कोड में, सार्वजनिक विधि की पहली पंक्ति इस तरह जाती है:

ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();

ध्यान दें कि addParam () स्वयं लौटाता है, ताकि आप जांच के लिए और अधिक पैरामीटर जोड़ सकें।

यदि कोई पैरामीटर शून्य है (चेक किया गया है या अनचेक किया गया है तो एक डिज़ाइन / स्वाद समस्या है, लेकिन मेरी जांच की गई है) विधि validate()को फेंक दिया जाएगा ।ValidationExceptionValidationException

void validate() throws ValidationException;

संदेश में निम्न पाठ होगा, उदाहरण के लिए, "योजनाएं" शून्य है:

" अवैध तर्क मान शून्य पैरामीटर [योजना] के लिए सामना किया जाता है "

जैसा कि आप देख सकते हैं, उपयोगकर्ता संदेश के लिए addParam () विधि (स्ट्रिंग) में दूसरा मान आवश्यक है, क्योंकि आप आसानी से पारदर्शी नाम का पता नहीं लगा सकते हैं, यहां तक ​​कि प्रतिबिंब के साथ भी (इस पोस्ट का विषय वैसे भी नहीं ...)।

और हां, हम जानते हैं कि इस लाइन से परे हमें अब एक शून्य मूल्य नहीं मिलेगा, इसलिए हम उन वस्तुओं पर सुरक्षित रूप से तरीकों का आह्वान करते हैं।

इस तरह, कोड स्वच्छ, आसान रखरखाव और पठनीय है।


गुवा, Google द्वारा एक बहुत उपयोगी कोर लाइब्रेरी, नल से बचने के लिए एक अच्छा और उपयोगी एपीआई है। मैं उपयोग कर रहा हूँ Guava बहुत उपयोगी है।

विकी में समझाया गया है:

Optional<T>एक गैर-शून्य मान के साथ एक शून्य टी संदर्भ को बदलने का एक तरीका है। एक वैकल्पिक में या तो एक गैर-शून्य टी संदर्भ हो सकता है (जिस स्थिति में हम कहते हैं कि संदर्भ "वर्तमान" है), या इसमें कुछ भी नहीं हो सकता है (जिस स्थिति में हम कहते हैं कि संदर्भ "अनुपस्थित" है)। इसे "शून्य" रखने के लिए कभी नहीं कहा जाता है।

उपयोग:

Optional<Integer> possible = Optional.of(5);
possible.isPresent(); // returns true
possible.get(); // returns 5

जावा 7 में एक नई java.util.Objectsउपयोगिता कक्षा है जिस पर एक requireNonNull()विधि है। NullPointerExceptionयदि यह तर्क शून्य है, तो यह सब फेंक दिया जाता है, लेकिन यह कोड को थोड़ा सा साफ़ करता है। उदाहरण:

Objects.requireNonNull(someObject);
someObject.doCalc();

यह विधि किसी कन्स्ट्रक्टर में असाइनमेंट से पहले checking लिए सबसे उपयोगी है , जहां इसका प्रत्येक उपयोग कोड की तीन पंक्तियों को बचा सकता है:

Parent(Child child) {
   if (child == null) {
      throw new NullPointerException("child");
   }
   this.child = child;
}

हो जाता है

Parent(Child child) {
   this.child = Objects.requireNonNull(child, "child");
}

बस शून्य का उपयोग न करें। इसे अनुमति न दें।

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

एक बार मैंने इस अभ्यास को अपनाया, मैंने देखा कि समस्याएं खुद को ठीक करने लगती हैं। आप केवल दुर्घटना से विकास प्रक्रिया में चीजों को पकड़ लेंगे और महसूस करेंगे कि आपके पास कमजोर जगह थी .. और सबसे महत्वपूर्ण बात यह है कि यह विभिन्न मॉड्यूल की चिंताओं को समाहित करने में मदद करता है, विभिन्न मॉड्यूल एक-दूसरे पर भरोसा कर सकते हैं, और अब और कूड़ेदान नहीं कर सकते के साथ कोडif = null else संरचना !

यह रक्षात्मक प्रोग्रामिंग है और लंबे समय तक अधिक क्लीनर कोड में परिणाम देता है। हमेशा डेटा को स्वच्छ करें, उदाहरण के लिए कठोर मानकों को लागू करके, और समस्याएं दूर हो जाएं।

class C {
    private final MyType mustBeSet;
    public C(MyType mything) {
       mustBeSet=Contract.notNull(mything);
    }
   private String name = "<unknown>";
   public void setName(String s) {
      name = Contract.notNull(s);
   }
}


class Contract {
    public static <T> T notNull(T t) { if (t == null) { throw new ContractException("argument must be non-null"); return t; }
}

अनुबंध मिनी-यूनिट परीक्षणों की तरह हैं जो हमेशा उत्पादन में होते हैं, और जब चीजें असफल होती हैं, तो आप जानते हैं कि क्यों एक यादृच्छिक एनपीई के बजाय आपको किसी भी तरह का पता लगाना है।


मुझे नेट प्राइस से लेख पसंद हैं। यहां लिंक हैं:

लेखों में जावा के लिए गिट रिपोजिटरी का एक लिंक भी हो सकता है, जो मुझे दिलचस्प लगता है, लेकिन मुझे नहीं लगता कि यह अकेले चेकिंग कोड ब्लोट को कम कर सकता है। इंटरनेट पर कुछ शोध करने के बाद, मुझे लगता है ! = नल कोड ब्लोट को मुख्य रूप से सावधान डिजाइन से कम किया जा सकता है।


मैंने कोशिश की है NullObjectPatternलेकिन मेरे लिए हमेशा जाने का सबसे अच्छा तरीका नहीं है। कभी-कभी जब कोई "कोई कार्रवाई नहीं" अपरिपक्व नहीं होती है।

NullPointerExceptionएक रनटाइम अपवाद है जिसका अर्थ कि यह डेवलपर गलती है और पर्याप्त अनुभव के साथ यह आपको बताता है कि त्रुटि कहां है।

अब जवाब के लिए:

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

बेशक, अनुभव इस सुझाव को समझने और लागू करने का बेहतर तरीका है।

बाइट!


यह पूछकर कि सवाल बताता है कि आपको त्रुटि प्रबंधन रणनीतियों में रुचि हो सकती है। आपकी टीम के आर्किटेक्ट को यह तय करना चाहिए कि त्रुटियों को कैसे काम करना है। इसे करने बहुत सारे तरीके हैं:

  1. अपवादों को घुमाने के लिए अनुमति दें - उन्हें 'मुख्य पाश' या किसी अन्य प्रबंधन दिनचर्या में पकड़ें।

    • त्रुटि की स्थिति की जांच करें और उन्हें उचित रूप से संभाल लें

निश्चित रूप से आस्पेक्ट ओरिएंटेड प्रोग्रामिंग पर भी एक नज़र डालें, उनके पास if( o == null ) handleNull()आपके बाइटकोड में डालने के साफ-सुथरे तरीके हैं ।


शायद जावा 8 या नए के लिए सबसे अच्छा विकल्प Optionalवर्ग का उपयोग करना है ।

Optional stringToUse = Optional.of("optional is there");
stringToUse.ifPresent(System.out::println);

यह संभावित शून्य मूल्यों की लंबी श्रृंखला के लिए विशेष रूप से आसान है। उदाहरण:

Optional<Integer> i = Optional.ofNullable(wsObject.getFoo())
    .map(f -> f.getBar())
    .map(b -> b.getBaz())
    .map(b -> b.getInt());

नल पर अपवाद फेंकने के उदाहरण पर उदाहरण:

Optional optionalCarNull = Optional.ofNullable(someNull);
optionalCarNull.orElseThrow(IllegalStateException::new);

जावा 7 ने Objects.requireNonNullविधि को पेश किया जो गैर-शून्यता के लिए कुछ जांचने पर आसान हो सकता है। उदाहरण:

String lowerVal = Objects.requireNonNull(someVar, "input cannot be null or empty").toLowerCase();

public static <T> T ifNull(T toCheck, T ifNull) {
    if (toCheck == null) {
           return ifNull;
    }
    return toCheck;
}




null