Evitare! = Dichiarazioni null

Uso object != nullmolto per evitare NullPointerException.

C'è una buona alternativa a questo?

Ad esempio, utilizzo spesso:

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

Questa verifica la presenza di una NullPointerExceptionper l' someobjectoggetto in questo frammento di codice.

Si noti che la risposta accettata potrebbe non essere aggiornata, consultare https://stackoverflow.com/a/2386013/12943 per un approccio più recente.

Questo per me suona come un problema ragionevolmente comune che gli sviluppatori da junior a intermedi tendono ad affrontare ad un certo punto: o non conoscono o non si fidano dei contratti a cui partecipano e superano difensivamente i null. Inoltre, quando scrivono il proprio codice, tendono a fare affidamento sulla restituzione di valori null per indicare qualcosa che richiede quindi al chiamante di verificare la presenza di valori null.

In altre parole, ci sono due casi in cui viene visualizzato il controllo null:

1. Dove null è una risposta valida in termini di contratto; e

2. Dove non è una risposta valida.

(2) è facile. Utilizzare assertistruzioni (asserzioni) o consentire errori (ad esempio NullPointerException ). Le asserzioni sono una funzionalità Java molto sottoutilizzata che è stata aggiunta in 1.4. La sintassi è:

assert <condition>

o

assert <condition> : <object>

dove <condition>è un'espressione booleana ed <object>è un oggetto il cui toString()output del metodo verrà incluso nell'errore.

Un'istruzione assertgenera un Error( AssertionError) se la condizione non è vera. Per impostazione predefinita, Java ignora le asserzioni. È possibile abilitare le asserzioni passando l'opzione -eaalla JVM. È possibile abilitare e disabilitare le asserzioni per singole classi e pacchetti. Ciò significa che è possibile convalidare il codice con le asserzioni durante lo sviluppo e il test e disabilitarle in un ambiente di produzione, anche se i miei test hanno mostrato quasi nessun impatto sulle prestazioni da parte delle asserzioni.

Non usare le asserzioni in questo caso è OK perché il codice fallirà, che è ciò che accadrà se si usano le asserzioni. L'unica differenza è che con le asserzioni potrebbe accadere prima, in modo più significativo e possibilmente con informazioni aggiuntive, il che potrebbe aiutarti a capire perché è successo se non te lo aspettavi.

(1) è un po 'più difficile. Se non hai alcun controllo sul codice che stai chiamando, sei bloccato. Se null è una risposta valida, devi verificarla.

Se è il codice che controlli, tuttavia (e questo è spesso il caso), allora è una storia diversa. Evitare di utilizzare null come risposta. Con i metodi che restituiscono raccolte, è facile: restituire raccolte vuote (o matrici) invece di null praticamente sempre.

Con le non-collezioni potrebbe essere più difficile. Considera questo come esempio: se hai queste interfacce:

public interface Action {
  void doSomething();
}

public interface Parser {
  Action findAction(String userInput);
}

dove Parser accetta input utente non elaborati e trova qualcosa da fare, forse se stai implementando un'interfaccia della riga di comando per qualcosa. Ora è possibile rendere nullo il contratto se non viene eseguita alcuna azione appropriata. Questo porta al controllo nullo di cui stai parlando.

Una soluzione alternativa è non restituire mai null e utilizzare invece il modello Null Object :

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }
}

Confrontare:

Parser parser = ParserFactory.getParser();
if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
  // do nothing
} else {
  action.doSomething();
}

per

ParserFactory.getParser().findAction(someInput).doSomething();

che è un design molto migliore perché porta a un codice più conciso.

Detto questo, forse è del tutto appropriato per il metodo findAction () generare un'eccezione con un messaggio di errore significativo, specialmente in questo caso in cui si fa affidamento sull'input dell'utente. Sarebbe molto meglio per il metodo findAction generare un'eccezione piuttosto che per il metodo chiamante esplodere con una semplice NullPointerException senza alcuna spiegazione.

try {
    ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());
}

Oppure, se ritieni che il meccanismo try / catch sia troppo brutto, piuttosto che Non fare nulla, l'azione predefinita dovrebbe fornire un feedback all'utente.

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }
}

Se si utilizza (o si prevede di utilizzare) un IDE Java come JetBrains IntelliJ IDEA , Eclipse o Netbeans o uno strumento come findbugs, è possibile utilizzare le annotazioni per risolvere questo problema.

Fondamentalmente, hai @Nullablee @NotNull.

È possibile utilizzare in metodo e parametri, in questo modo:

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

o

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

Il secondo esempio non verrà compilato (in IntelliJ IDEA).

Quando si utilizza la prima helloWorld()funzione in un altro codice:

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

Ora il compilatore IDEA IntelliJ ti dirà che il controllo è inutile, poiché la helloWorld()funzione non tornerà nullmai.

Utilizzando il parametro

void someMethod(@NotNull someParameter) { }

se scrivi qualcosa del tipo:

someMethod(null);

Questo non verrà compilato.

Ultimo esempio usando @Nullable

@Nullable iWantToDestroyEverything() { return null; }

Facendo questo

iWantToDestroyEverything().something();

E puoi essere sicuro che ciò non accadrà. :)

È un buon modo per consentire al compilatore di controllare qualcosa di più di quanto non faccia normalmente e per far rispettare i contratti. Sfortunatamente, non è supportato da tutti i compilatori.

In IntelliJ IDEA 10.5 e versioni successive, hanno aggiunto il supporto per qualsiasi altra @Nullable @NotNullimplementazione.

Vedi post sul blog Annotazioni @ Nullable / @ NotNull più flessibili e configurabili .

Se i valori null non sono ammessi

Se il tuo metodo viene chiamato esternamente, inizia con qualcosa del genere:

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

Quindi, nel resto di quel metodo, saprai che objectnon è null.

Se è un metodo interno (non parte di un'API), basta documentare che non può essere nullo e basta.

Esempio:

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

Tuttavia, se il tuo metodo passa semplicemente il valore e il metodo successivo lo passa ecc., Potrebbe diventare problematico. In tal caso, potresti voler controllare l'argomento come sopra.

Se è consentito null

Questo dipende davvero. Se scopri che spesso faccio qualcosa del genere:

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

Quindi mi dirigo e faccio due cose completamente diverse. Non esiste uno snippet di codice brutto, perché ho davvero bisogno di fare due cose diverse a seconda dei dati. Ad esempio, dovrei lavorare sull'input o dovrei calcolare un buon valore predefinito?

In realtà è raro per me usare il linguaggio " if (object != null && ...".

Potrebbe essere più semplice fornirti degli esempi, se mostri esempi di dove in genere usi il linguaggio.

Wow, quasi odio aggiungere un'altra risposta quando abbiamo 57 modi diversi di raccomandare il NullObject pattern, ma penso che alcune persone interessate a questa domanda potrebbero sapere che esiste una proposta sul tavolo per Java 7 che aggiunge "null-safe gestione ": una sintassi semplificata per la logica if-not-equal-null.

L'esempio fornito da Alex Miller è simile al seguente:

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

Il ?.mezzo rimuove il riferimento all'identificatore sinistro solo se non è nullo, altrimenti valuta il resto dell'espressione come null. Alcune persone, come Dick Wall, membro di Java Posse e gli elettori di Devoxx adorano davvero questa proposta, ma c'è anche un'opposizione, in quanto incoraggerà effettivamente un maggiore utilizzo nullcome valore sentinella.

Aggiornamento: una proposta ufficiale per un operatore null-safe in Java 7 è stata presentata sotto Project Coin. La sintassi è leggermente diversa dall'esempio sopra, ma è la stessa nozione.

Aggiornamento: la proposta dell'operatore null-safe non è diventata Project Coin. Quindi, non vedrai questa sintassi in Java 7.

Se valori non definiti non sono consentiti:

È possibile configurare il proprio IDE per avvisare l'utente del potenziale dereferenziamento nullo. Ad esempio in Eclipse, vedi Preferenze> Java> Compilatore> Errori / Avvertenze / Analisi nulla .

Se sono consentiti valori non definiti:

Se si desidera definire una nuova API in cui i valori non definiti hanno senso , utilizzare il modello di opzione (potrebbe essere familiare dai linguaggi funzionali). Ha i seguenti vantaggi:

• Viene indicato esplicitamente nell'API se esiste o meno un input o un output.
• Il compilatore ti costringe a gestire il caso "non definito".
• L'opzione è una monade , quindi non è necessario un controllo nullo dettagliato, basta usare map / foreach / getOrElse o un combinatore simile per usare in sicurezza il valore (esempio) .

Java 8 ha una Optionalclasse integrata (consigliata); per le versioni precedenti, non ci sono alternative di libreria, ad esempio Guava 's Optionalo FunctionalJava ' s Option. Ma come molti modelli di stile funzionale, l'utilizzo di Option in Java (anche 8) porta a un po 'di plateplate, che è possibile ridurre usando un linguaggio JVM meno prolisso, ad esempio Scala o Xtend.

Se hai a che fare con un'API che potrebbe restituire valori null , non puoi fare molto in Java. Xtend e Groovy hanno l' operatore Elvis ?: e l' operatore di dereference null-safe ?. , ma si noti che questo restituisce null in caso di riferimento null, quindi "difende" la corretta gestione di null.

Solo per questa situazione -

Non verificare se una variabile è nulla prima di invocare un metodo uguale (di seguito un esempio di confronto di stringhe):

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

comporterà un NullPointerExceptionse foonon esiste.

Puoi evitarlo confrontando le tue in Stringquesto modo:

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

Con Java 8 arriva la nuova java.util.Optionalclasse che probabilmente risolve parte del problema. Si può almeno dire che migliora la leggibilità del codice e nel caso delle API pubbliche rendono più chiaro il contratto dell'API allo sviluppatore del client.

Funzionano così:

Un oggetto facoltativo per un determinato tipo ( Fruit) viene creato come tipo restituito di un metodo. Può essere vuoto o contenere un Fruitoggetto:

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();
}

Ora guarda questo codice dove cerchiamo un elenco di Fruit( fruits) per una determinata istanza di Fruit:

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

È possibile utilizzare l' map()operatore per eseguire un calcolo su - o estrarre un valore da - un oggetto opzionale. orElse()consente di fornire un fallback per i valori mancanti.

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

Ovviamente, il controllo per valore nullo / vuoto è ancora necessario, ma almeno lo sviluppatore è consapevole che il valore potrebbe essere vuoto e il rischio di dimenticare di controllare è limitato.

In un'API creata da zero utilizzando Optionalogni volta che un valore restituito potrebbe essere vuoto e restituendo un oggetto semplice solo quando non può essere null(convenzione), il codice client potrebbe abbandonare i controlli null su valori restituiti oggetto semplice ...

Naturalmente Optionalpotrebbe anche essere usato come argomento del metodo, forse un modo migliore per indicare argomenti opzionali rispetto a 5 o 10 metodi di sovraccarico in alcuni casi.

Optionaloffre altri metodi convenienti, come quello orElseche consente l'uso di un valore predefinito e ifPresentche funziona con le espressioni lambda .

Vi invito a leggere questo articolo (la mia fonte principale per scrivere questa risposta) in cui la soluzione NullPointerException(e in generale il puntatore nullo) problematica e la (parziale) soluzione proposta Optionalsono ben spiegate: Java Optional Objects .

A seconda del tipo di oggetti che stai controllando potresti essere in grado di usare alcune delle classi nei beni comuni di Apache come: apache commons lang e apache commons collection

Esempio:

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

oppure (a seconda di cosa è necessario controllare):

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

La classe StringUtils è solo una delle tante; ci sono alcune buone classi nei beni comuni che manipolano in modo sicuro.

Ecco un esempio di come è possibile utilizzare la null null in JAVA quando si include la libreria apache (commons-lang-2.4.jar)

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

E se stai usando Spring, Spring ha anche la stessa funzionalità nel suo pacchetto, vedi library (spring-2.4.6.jar)

Esempio su come utilizzare questa classe statica dalla primavera (org.springframework.util.Assert)

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

• Se consideri un oggetto non dovrebbe essere nullo (o è un bug) usa un'asserzione.
• Se il tuo metodo non accetta parametri null, dillo nel javadoc e usa un'asserzione.

Devi controllare l'oggetto! = Null solo se vuoi gestire il caso in cui l'oggetto potrebbe essere null ...

C'è una proposta per aggiungere nuove annotazioni in Java7 per aiutare con i parametri null / notnull: http://tech.puredanger.com/java7/#jsr308

Sono un fan del codice "fail fast". Chiediti: stai facendo qualcosa di utile nel caso in cui il parametro sia nullo? Se non hai una risposta chiara a ciò che il tuo codice dovrebbe fare in quel caso ... Vale a dire che non dovrebbe mai essere nullo in primo luogo, quindi ignoralo e lascia che venga generata una NullPointerException. Il codice chiamante avrà lo stesso senso di un NPE come se fosse un IllegalArgumentException, ma sarà più facile per lo sviluppatore eseguire il debug e capire cosa è andato storto se viene lanciato un NPE anziché il codice che tenta di eseguire qualche altra imprevista imprevista logica - che alla fine porta comunque al fallimento dell'applicazione.

Il framework delle raccolte di Google offre un modo valido ed elegante per ottenere il controllo null.

Esiste un metodo in una classe di libreria come questo:

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

E l'uso è (con import static):

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

O nel tuo esempio:

checkNotNull(someobject).doCalc();

A volte, hai metodi che operano sui suoi parametri che definiscono un'operazione simmetrica:

a.f(b); <-> b.f(a);

Se sai che b non può mai essere nullo, puoi semplicemente scambiarlo. È più utile per uguali: invece di foo.equals("bar");fare meglio "bar".equals(foo);.

Piuttosto che Null Object Pattern - che ha i suoi usi - potresti considerare situazioni in cui l'oggetto null è un bug.

Quando viene generata l'eccezione, esaminare la traccia dello stack e risolvere il problema.

Null non è un "problema". È parte integrante di un set completo di strumenti di modellazione. Il software mira a modellare la complessità del mondo e null sopporta il suo peso. Null indica "Nessun dato" o "Sconosciuto" in Java e simili. Quindi è appropriato usare null per questi scopi. Non preferisco il modello "Null object"; Penso che sorga il problema di " chi custodirà i guardiani ".
Se mi chiedi come si chiama la mia ragazza ti dirò che non ho una ragazza. Nel linguaggio Java restituirò null. Un'alternativa sarebbe quella di gettare un'eccezione significativa per indicare qualche problema che non può essere (o non

1. Per una "domanda sconosciuta", fornire "risposta sconosciuta". (Essere null-safe dove questo è corretto dal punto di vista aziendale) Il controllo degli argomenti per null una volta all'interno di un metodo prima dell'utilizzo allevia più chiamanti dal controllarli prima di una chiamata.

   public Photo getPhotoOfThePerson(Person person) {
       if (person == null)
           return null;
       // Grabbing some resources or intensive calculation
       // using person object anyhow.
   }

   Il precedente portava al normale flusso logico per non ottenere foto di una ragazza inesistente dalla mia libreria di foto.

   getPhotoOfThePerson(me.getGirlfriend())

   E si adatta alla nuova API Java in arrivo (in attesa)

   getPhotoByName(me.getGirlfriend()?.getName())

   Mentre è piuttosto 'normale flusso di affari' non trovare foto archiviate nel DB per alcune persone, in alcuni casi usavo le coppie come sotto

   public static MyEnum parseMyEnum(String value); // throws IllegalArgumentException
   public static MyEnum parseMyEnumOrNull(String value);

   E non detestare di digitare <alt> + <shift> + <j>(generare javadoc in Eclipse) e scrivere tre parole aggiuntive per l'API pubblica. Questo sarà più che sufficiente per tutti tranne quelli che non leggono la documentazione.

   /**
    * @return photo or null
    */

   o

   /**
    * @return photo, never null
    */

2. Questo è un caso piuttosto teorico e nella maggior parte dei casi dovresti preferire l'API java null safe (nel caso in cui verrà rilasciato tra altri 10 anni), ma NullPointerExceptionè una sottoclasse di un Exception. Quindi è una forma Throwableche indica le condizioni che un'applicazione ragionevole potrebbe voler catturare ( javadoc )! Per utilizzare il primo maggior vantaggio di eccezioni e separare il codice di gestione degli errori dal codice "normale" ( secondo i creatori di Java ) è opportuno, per quanto mi riguarda, catturare NullPointerException.

   public Photo getGirlfriendPhoto() {
       try {
           return appContext.getPhotoDataSource().getPhotoByName(me.getGirlfriend().getName());
       } catch (NullPointerException e) {
           return null;
       }
   }

   Potrebbero sorgere domande:

   D. Cosa succede se getPhotoDataSource()restituisce null?
   A. Dipende dalla logica aziendale. Se non riesco a trovare un album fotografico, non ti mostrerò foto. Cosa succede se appContext non è inizializzato? La logica aziendale di questo metodo lo sopporta. Se la stessa logica deve essere più rigorosa, quindi lanciare un'eccezione fa parte della logica aziendale e deve essere utilizzato il controllo esplicito per null (caso 3). La nuova API Java Null-safe si adatta meglio qui per specificare in modo selettivo cosa implica e cosa non implica essere inizializzato per essere fail-fast in caso di errori del programmatore.

   D. Il codice ridondante potrebbe essere eseguito e le risorse non necessarie potrebbero essere catturate.
   R. Potrebbe avvenire se getPhotoByName()provasse ad aprire una connessione al database, a creare PreparedStatemente utilizzare il nome della persona come parametro SQL alla fine. L'approccio per una domanda sconosciuta dà una risposta sconosciuta (caso 1) funziona qui. Prima di afferrare le risorse il metodo dovrebbe controllare i parametri e restituire risultati "sconosciuti" se necessario.

   D. Questo approccio ha una penalità prestazionale a causa dell'apertura della chiusura di prova.
   A. Il software dovrebbe essere facile da capire e modificare in primo luogo. Solo dopo questo, si potrebbe pensare alle prestazioni e solo se necessario! e dove necessario! ( fonte ) e molti altri).

   PS. Questo approccio sarà ragionevole da usare come il codice di gestione degli errori separato dal principio del codice "normale" è ragionevole da usare in qualche luogo. Considera il prossimo esempio:

   public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
       try {
           Result1 result1 = performSomeCalculation(predicate);
           Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
           Result3 result3 = performThirdCalculation(result2.getSomeProperty());
           Result4 result4 = performLastCalculation(result3.getSomeProperty());
           return result4.getSomeProperty();
       } catch (NullPointerException e) {
           return null;
       }
   }
   
   public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
       SomeValue result = null;
       if (predicate != null) {
           Result1 result1 = performSomeCalculation(predicate);
           if (result1 != null && result1.getSomeProperty() != null) {
               Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
               if (result2 != null && result2.getSomeProperty() != null) {
                   Result3 result3 = performThirdCalculation(result2.getSomeProperty());
                   if (result3 != null && result3.getSomeProperty() != null) {
                       Result4 result4 = performLastCalculation(result3.getSomeProperty());
                       if (result4 != null) {
                           result = result4.getSomeProperty();
                       }
                   }
               }
           }
       }
       return result;
   }

   PPS. Per coloro che hanno una rapida votazione (e non così veloce da leggere la documentazione), vorrei dire che non ho mai preso un'eccezione null-pointer (NPE) in vita mia. Ma questa possibilità è stata intenzionalmente progettata dai creatori di Java perché NPE è una sottoclasse di Exception. Abbiamo un precedente nella storia Java quando ThreadDeathè un Errornon perché è in realtà un errore di applicazione, ma solo perché non era destinato a essere catturati! Quanto NPE si adatta ad essere un Errordi ThreadDeath! Ma non è.

3. Controlla "Nessun dato" solo se la logica aziendale lo implica.

   public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
       if (personId == null)
           return;
       DataSource dataSource = appContext.getStuffDataSource();
       Person person = dataSource.getPersonById(personId);
       if (person != null) {
           person.setPhoneNumber(phoneNumber);
           dataSource.updatePerson(person);
       } else {
           Person = new Person(personId);
           person.setPhoneNumber(phoneNumber);
           dataSource.insertPerson(person);
       }
   }

   e

   public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
       if (personId == null)
           return;
       DataSource dataSource = appContext.getStuffDataSource();
       Person person = dataSource.getPersonById(personId);
       if (person == null)
           throw new SomeReasonableUserException("What are you thinking about ???");
       person.setPhoneNumber(phoneNumber);
       dataSource.updatePerson(person);
   }

   Se appContext o dataSource non sono inizializzati, il runtime non gestito NullPointerException ucciderà il thread corrente e verrà elaborato da Thread.defaultUncaughtExceptionHandler (per poter definire e utilizzare il proprio logger preferito o altro meccanismo di notifica). Se non impostato, ThreadGroup # uncaughtException stamperà stacktrace su err di sistema. Si dovrebbe monitorare il registro degli errori dell'applicazione e aprire il problema di Jira per ogni eccezione non gestita che in realtà è un errore dell'applicazione. Il programmatore dovrebbe correggere bug da qualche parte nelle cose di inizializzazione.

Java 7 ha una nuova java.util.Objectsclasse di utilità su cui esiste un requireNonNull()metodo. Tutto ciò che fa è lanciare a NullPointerExceptionse il suo argomento è null, ma pulisce un po 'il codice. Esempio:

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

Il metodo è più utile per verificare poco prima di un'assegnazione in un costruttore, in cui ogni suo utilizzo può salvare tre righe di codice:

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

diventa

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

In definitiva, l'unico modo per risolvere completamente questo problema è usare un linguaggio di programmazione diverso:

• In Objective-C, puoi fare l'equivalente di invocare un metodo nile non accadrà assolutamente nulla. Ciò rende superflui i controlli null, ma può rendere gli errori molto più difficili da diagnosticare.
• A Nizza , un linguaggio derivato da Java, esistono due versioni di tutti i tipi: una versione potenzialmente nulla e una versione non nulla. È possibile richiamare metodi solo su tipi non nulli. I tipi potenzialmente nulli possono essere convertiti in tipi non nulli mediante controllo esplicito per null. Ciò rende molto più semplice sapere dove sono necessari controlli null e dove non lo sono.

"Problema" comune in Java davvero.

Innanzitutto, i miei pensieri su questo:

Ritengo che sia male "mangiare" qualcosa quando viene passato NULL in cui NULL non è un valore valido. Se non esci dal metodo con una sorta di errore, significa che nulla è andato storto nel tuo metodo, il che non è vero. Quindi probabilmente restituisci null in questo caso, e nel metodo di ricezione controlli di nuovo null, e non finisce mai, e finisci con "if! = Null", ecc.

Quindi, IMHO, null deve essere un errore critico che impedisce ulteriori esecuzioni (ovvero, dove null non è un valore valido).

Il modo in cui risolvo questo problema è questo:

Innanzitutto, seguo questa convenzione:

1. Tutti i metodi / API pubblici controllano sempre i suoi argomenti per null
2. Tutti i metodi privati ​​non controllano la presenza di null poiché sono metodi controllati (basta lasciar morire con eccezione nullpointer nel caso in cui non sia stato gestito sopra)
3. Gli unici altri metodi che non verificano la presenza di null sono i metodi di utilità. Sono pubblici, ma se li chiami per qualche motivo, sai quali parametri passi. È come cercare di far bollire l'acqua nel bollitore senza fornire acqua ...

E infine, nel codice, la prima riga del metodo pubblico va così:

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

Si noti che addParam () restituisce self, quindi è possibile aggiungere più parametri da verificare.

Il metodo validate()verrà verificato ValidationExceptionse uno qualsiasi dei parametri è null (selezionato o deselezionato è più un problema di progettazione / gusto, ma il mio ValidationExceptionè selezionato).

void validate() throws ValidationException;

Il messaggio conterrà il testo seguente se, ad esempio, "piani" è nullo:

" Rilevato valore dell'argomento non valido null per il parametro [piani] "

Come puoi vedere, il secondo valore nel metodo addParam () (stringa) è necessario per il messaggio utente, perché non puoi facilmente rilevare il nome della variabile passata, anche con la riflessione (comunque non oggetto di questo post ...).

E sì, sappiamo che oltre questa linea non incontreremo più un valore nullo, quindi invocheremo metodi in modo sicuro su quegli oggetti.

In questo modo, il codice è pulito, facilmente gestibile e leggibile.

Fare questa domanda sottolinea che potresti essere interessato alle strategie di gestione degli errori. L'architetto del tuo team dovrebbe decidere come risolvere gli errori. Esistono diversi modi per farlo:

1. consentire alle eccezioni di passare attraverso - catturarle nel "ciclo principale" o in qualche altra routine di gestione.

   • controllare le condizioni di errore e gestirle in modo appropriato

Sicuramente dai un'occhiata anche alla programmazione orientata agli aspetti: hanno dei modi ben precisi da inserire if( o == null ) handleNull()nel tuo bytecode.

Oltre a utilizzare assertè possibile utilizzare quanto segue:

if (someobject == null) {
    // Handle null here then move on.
}

Questo è leggermente meglio di:

if (someobject != null) {
    .....
    .....



    .....
}

Non usare mai null. Non permetterlo.

Nelle mie classi, la maggior parte dei campi e delle variabili locali hanno valori predefiniti non nulli e aggiungo dichiarazioni di contratto (asserzioni sempre attive) ovunque nel codice per assicurarmi che questo venga applicato (poiché è più conciso e più espressivo che lasciarlo venire come un NPE e quindi dover risolvere il numero di riga, ecc.).

Una volta adottata questa pratica, ho notato che i problemi sembravano risolversi da soli. Prenderesti le cose molto prima nel processo di sviluppo solo per caso e ti rendevi conto di avere un punto debole ... e, cosa più importante, aiuta a incapsulare le preoccupazioni dei diversi moduli, i diversi moduli possono "fidarsi" l'uno dell'altro, e non più sporcare il codice con if = null elsecostrutti!

Questa è una programmazione difensiva e si traduce in un codice molto più pulito a lungo termine. Disinfettare sempre i dati, ad esempio qui applicando standard rigidi e i problemi scompaiono.

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; }
}

I contratti sono come test di mini-unità che sono sempre in esecuzione, anche in produzione, e quando le cose falliscono, sai perché, piuttosto che un NPE casuale devi in ​​qualche modo capire.

Guava, una libreria di base molto utile di Google, ha un'API bella e utile per evitare i null. Trovo che UsingAndAvoidingNullExplained sia stato molto utile.

Come spiegato nel wiki:

Optional<T>è un modo per sostituire un riferimento T nullable con un valore non nullo. Un Opzionale può contenere un riferimento T non nullo (nel qual caso diciamo che il riferimento è "presente"), oppure può non contenere nulla (nel qual caso diciamo che il riferimento è "assente"). Non si dice mai che "contenga null".

Uso:

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

Questo è un problema molto comune per ogni sviluppatore Java. Quindi esiste un supporto ufficiale in Java 8 per affrontare questi problemi senza codice disordinato.

Java 8 ha introdotto java.util.Optional<T>. È un contenitore che può contenere o meno un valore non nullo. Java 8 ha fornito un modo più sicuro per gestire un oggetto il cui valore può essere nullo in alcuni casi. Si ispira alle idee di Haskell e Scala .

In breve, la classe Optional include metodi per trattare esplicitamente i casi in cui un valore è presente o assente. Tuttavia, il vantaggio rispetto ai riferimenti null è che la classe <T> opzionale ti costringe a pensare al caso in cui il valore non è presente. Di conseguenza, è possibile impedire eccezioni indesiderate del puntatore null.

Nell'esempio sopra abbiamo una fabbrica di servizi domestici che restituisce una maniglia a più apparecchi disponibili in casa. Ma questi servizi potrebbero essere o non essere disponibili / funzionali; significa che potrebbe provocare una NullPointerException. Invece di aggiungere una ifcondizione nulla prima di utilizzare qualsiasi servizio, includiamola in <Servizio> opzionale.

AVVOLGIMENTO ALL'OPZIONE <T>

Consideriamo un metodo per ottenere un riferimento di un servizio da una fabbrica. Invece di restituire il riferimento del servizio, avvolgerlo con Opzionale. Fa sapere all'utente API che il servizio restituito può o meno essere disponibile / funzionale, utilizzare in modo difensivo

public Optional<Service> getRefrigertorControl() {
      Service s = new  RefrigeratorService();
       //...
      return Optional.ofNullable(s);
   }

Come vedi Optional.ofNullable()fornisce un modo semplice per ottenere il riferimento spostato. Esistono altri modi per ottenere il riferimento di Facoltativo, e Optional.empty()& Optional.of(). Uno per restituire un oggetto vuoto invece di risintonizzare null e l'altro per avvolgere un oggetto non nullable, rispettivamente.

COSÌ COME ESATTAMENTE AIUTA A EVITARE UN CONTROLLO NULL?

Dopo aver avvolto un oggetto di riferimento, Opzionale fornisce molti metodi utili per invocare metodi su un riferimento a capo senza NPE.

Optional ref = homeServices.getRefrigertorControl();
ref.ifPresent(HomeServices::switchItOn);

Facoltativo.ifPresent richiama il consumatore specificato con un riferimento se si tratta di un valore non nullo. Altrimenti, non fa nulla.

@FunctionalInterface
public interface Consumer<T>

Rappresenta un'operazione che accetta un singolo argomento di input e non restituisce alcun risultato. A differenza della maggior parte delle altre interfacce funzionali, si prevede che il consumatore operi tramite effetti collaterali. È così pulito e facile da capire. Nell'esempio di codice sopra, HomeService.switchOn(Service)viene invocato se il riferimento di mantenimento opzionale è non nullo.

Usiamo l'operatore ternario molto spesso per verificare la condizione nulla e restituiamo un valore alternativo o un valore predefinito. Opzionale fornisce un altro modo per gestire la stessa condizione senza controllare null. Optional.orElse (defaultObj) restituisce defaultObj se l'Opzionale ha un valore nullo. Usiamo questo nel nostro codice di esempio:

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

Ora HomeServices.get () fa la stessa cosa, ma in un modo migliore. Verifica se il servizio è già stato inizializzato o meno. In tal caso, restituire lo stesso o creare un nuovo nuovo servizio. L'opzione <T> .orElse (T) consente di restituire un valore predefinito.

Infine, ecco il nostro NPE e il codice null check-free:

import java.util.Optional;
public class HomeServices {
    private static final int NOW = 0;
    private static Optional<HomeServices> service;

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

public Optional<Service> getRefrigertorControl() {
    Service s = new  RefrigeratorService();
    //...
    return Optional.ofNullable(s);
}

public static void main(String[] args) {
    /* Get Home Services handle */
    Optional<HomeServices> homeServices = HomeServices.get();
    if(homeServices != null) {
        Optional<Service> refrigertorControl = homeServices.get().getRefrigertorControl();
        refrigertorControl.ifPresent(HomeServices::switchItOn);
    }
}

public static void switchItOn(Service s){
         //...
    }
}

Il post completo è NPE e Null codice senza check ... Davvero? .

Mi piacciono gli articoli di Nat Pryce. Ecco i link:

• Evitare i null con spedizione polimorfica
• Evitare i nullità con lo stile "Tell, Don't Ask"

Negli articoli c'è anche un collegamento a un repository Git per un Java Maybe Type che trovo interessante, ma non credo che da solo potrebbe ridurre il gonfiore del codice di controllo. Dopo aver fatto qualche ricerca su Internet, penso ! = Il bloat del codice null potrebbe essere ridotto principalmente da un'attenta progettazione.

Ho provato il NullObjectPatternma per me non è sempre il modo migliore di andare. A volte ci sono quando una "nessuna azione" non è appropriata.

NullPointerExceptionè un'eccezione di runtime che significa che è colpa degli sviluppatori e con sufficiente esperienza ti dice esattamente dove si trova l'errore.

Ora alla risposta:

Cerca di rendere tutti i tuoi attributi e i suoi accessori il più privati ​​possibile o evita di esporli affatto ai clienti. Naturalmente puoi avere i valori degli argomenti nel costruttore, ma riducendo l'ambito non permetti alla classe client di passare un valore non valido. Se è necessario modificare i valori, è sempre possibile crearne uno nuovo object. Controlli i valori nel costruttore una sola volta e nel resto dei metodi puoi essere quasi sicuro che i valori non siano nulli.

Naturalmente, l'esperienza è il modo migliore per comprendere e applicare questo suggerimento.

Byte!

Probabilmente la migliore alternativa per Java 8 o più recente è usare la Optionalclasse.

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

Ciò è particolarmente utile per lunghe catene di possibili valori null. Esempio:

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

Esempio su come generare un'eccezione su null:

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

Java 7 ha introdotto il Objects.requireNonNullmetodo che può essere utile quando qualcosa deve essere verificato per nullità. Esempio:

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

Posso rispondere più in generale!

Di solito affrontiamo questo problema quando i metodi ottengono i parametri nel modo in cui non ci aspettavamo (una chiamata errata al metodo è colpa del programmatore). Ad esempio: ti aspetti di ottenere un oggetto, invece ottieni un null. Ti aspetti di ottenere una stringa con almeno un carattere, invece ottieni una stringa vuota ...

Quindi non c'è differenza tra:

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

}

o

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

Entrambi vogliono assicurarsi di aver ricevuto parametri validi, prima di eseguire qualsiasi altra funzione.

Come menzionato in alcune altre risposte, per evitare i problemi di cui sopra è possibile seguire il modello Design by contract . Si prega di consultare http://en.wikipedia.org/wiki/Design_by_contract .

Per implementare questo modello in Java, è possibile utilizzare le annotazioni core Java come javax.annotation.NotNull o utilizzare librerie più sofisticate come Hibernate Validator .

Solo un campione:

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

Ora puoi sviluppare in sicurezza la funzione principale del tuo metodo senza dover controllare i parametri di input, proteggendo i tuoi metodi da parametri imprevisti.

Puoi fare un passo ulteriore e assicurarti che nella tua applicazione possano essere creati solo pojos validi. (campione dal sito di validazione ibernazione)

public class Car {

   @NotNull
   private String manufacturer;

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

   @Min(2)
   private int seatCount;

   // ...
}

Ignoro fortemente le risposte che suggeriscono di usare gli oggetti null in ogni situazione. Questo modello può rompere il contratto e seppellire sempre più a fondo i problemi invece di risolverli, senza menzionare che l'uso improprio creerà un altro mucchio di codice della caldaia che richiederà una manutenzione futura.

In realtà, se qualcosa restituito da un metodo può essere nullo e il codice chiamante deve prendere una decisione al riguardo, dovrebbe esserci una chiamata precedente che assicura lo stato.

Inoltre, tieni presente che quel modello di oggetti null avrà fame di memoria se utilizzato senza cura. Per questo - l'istanza di un NullObject deve essere condivisa tra i proprietari e non essere un'istanza unigue per ognuno di questi.

Inoltre, non consiglierei di utilizzare questo modello in cui il tipo deve essere una rappresentazione di tipo primitivo - come entità matematiche, che non sono scalari: vettori, matrici, numeri complessi e oggetti POD (Plain Old Data), che devono contenere lo stato sotto forma di tipi predefiniti Java. In quest'ultimo caso si finirà per chiamare metodi getter con risultati arbitrari. Ad esempio, cosa dovrebbe restituire un metodo NullPerson.getName ()?

Vale la pena considerare questi casi per evitare risultati assurdi.

1. Non inizializzare mai le variabili su null.
2. Se (1) non è possibile, inizializzare tutte le raccolte e gli array per svuotare le raccolte / gli array.

Fallo nel tuo codice e puoi evitare! = Controlli null.

Il più delle volte i controlli null sembrano proteggere i loop da raccolte o array, quindi inizializzali vuoti, non avrai bisogno di controlli null.

// Bad
ArrayList<String> lemmings;
String[] names;

void checkLemmings() {
    if (lemmings != null) for(lemming: lemmings) {
        // do something
    }
}



// Good
ArrayList<String> lemmings = new ArrayList<String>();
String[] names = {};

void checkLemmings() {
    for(lemming: lemmings) {
        // do something
    }
}

C'è un piccolo sovraccarico in questo, ma ne vale la pena per un codice più pulito e meno NullPointerExceptions.

Questo è l'errore più comune che si è verificato per la maggior parte degli sviluppatori.

Abbiamo diversi modi per gestirlo.

Approccio 1:

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

notNull (oggetto Object, messaggio String)

Approccio 2:

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

Approccio 3:

@isNull @Nullable  // using annotation based validation

Approccio 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;
}

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