Uso object != null molto per evitare NullPointerException . C'è una buona alternativa a questo? Ad esempio:
if (someobject != null) {
someobject.doCalc();
}
Questo evita un NullPointerException , quando è sconosciuto se l'oggetto è null o meno.
In Java 8, è stata aggiunta una nuova funzione: Optional<> . Questo è per i campi che possono o non possono esserci ed è un'alternativa all'uso dei controlli nulli.
Se utilizzi Optional , puoi controllare se è presente o meno chiamando isPresent() , cioè
Optional<String> optionalString = Optional.of("Some string");
if (optionalString.isPresent()){
System.out.println(optinalString.get());
}
Optional<String> optionalString2 = Optional.ofNullable(null);
System.out.println(optionalString2.orElse("Some other string"));
Vedi i documenti all'indirizzo link .
Questo significa che solo Optionals non può avere alcun valore, se c'è un nullo in un altro posto che è un errore e dovrebbe essere permesso di lanciare un NPE, sebbene le librerie esterne possano ancora restituire null e quelle dovrebbero essere controllate.
Decidere se null è consentito come valore di un oggetto è una decisione che devi rendere consapevolmente per il tuo progetto.
Non devi accettare un costrutto linguistico solo perché esiste; infatti, spesso è meglio applicare una regola rigorosa contro qualsiasi null valori nell'intero progetto. Se lo fai, non hai bisogno di controlli; se una NullPointerException dovesse mai accadere, ciò significa automaticamente che c'è un difetto nel tuo codice, e non importa se questo è segnalato da un NPE o da qualche altro meccanismo di controllo di sanità mentale.
Se non puoi farlo, ad esempio perché devi interagire con altre librerie che consentono null , devi controllarlo. Anche allora è logico mantenere le aree del codice dove null è possibile, se possibile piccola. Quanto più grande è il progetto, tanto più ha senso definire un intero "strato anticorruzione" con l'unico scopo di preservare garanzie di valore più stringenti di quanto sia possibile altrove.
Se una variabile con valore null viene utilizzata nel tuo programma causando un NullPointerException , questa è chiaramente una situazione nel tuo programma che non ti aspetti. Devi porsi la domanda: "Non me l'aspettavo perché non ho preso in considerazione la possibilità di un valore null o ho presunto che il valore non potrebbe mai essere null qui?"
Se la risposta è la seconda, il problema non è perché non hai gestito il valore null . Il problema si è verificato in precedenza e stai vedendo solo le conseguenze di tale errore sulla riga in particolare utilizzata. In questo caso, aggiungere semplicemente if (variable != null) non lo taglierà. Finirai per saltare le righe che dovresti eseguire perché la variabile era null , e alla fine otterrai una riga più avanti in cui hai assunto nuovamente che non sarebbe null .
null deve essere utilizzato Come regola generale, restituisce null solo quando "assente" è un possibile valore di ritorno. In altre parole, il tuo livello dati può cercare un record con un ID specifico. Se quel record non viene trovato, puoi lanciare un'eccezione o semplicemente restituire null. Puoi fare entrambe le cose, ma preferisco non fare eccezioni in situazioni in cui esiste una strong possibilità. Quindi restituisci null invece di un valore.
Il chiamante di questo metodo, presumibilmente scritto da te, sa che esiste la possibilità che il record non esista e controlli null di conseguenza. Non c'è nulla di sbagliato in questo caso, anche se dovresti gestire questa possibilità il prima possibile, altrimenti in ogni parte del tuo programma dovrai affrontare la possibilità di un valore null .
In altre parole, considera null come valore legittimo, ma gestiscilo immediatamente anziché attendere. Idealmente nel tuo programma, dovresti sempre controllare se è null una volta nel tuo programma e solo nel luogo in cui viene gestito tale valore di null .
Per il valore ogni che ti aspetti di essere non nullo, non devi aggiungere un assegno. Se è null , accetta che vi sia un errore nel tuo programma quando è stato istanziato. In sostanza, il favore fallisce velocemente in caso di errore sicuro.