In che modo l'utilizzo delle librerie controlla i valori null meglio di NPE?

A volte vedo sviluppatori che utilizzano librerie come Precondizioni di Guava per convalidare i parametri per null all'inizio di un metodo. In che modo è diverso da ottenere NPE durante il runtime poiché si verifica un'eccezione di runtime in entrambi i modi?In che modo l'utilizzo delle librerie controlla i valori null meglio di NPE?

MODIFICA: Se ci sono buone ragioni, gli sviluppatori non dovrebbero utilizzare le librerie per il controllo null su tutti i metodi?

fonte

2015-01-22 Glide

Potrebbe essere che se controlli in anticipo non hai ancora lavorato, il lavoro che potresti dover ripristinare o lasciare in uno stato incoerente era un NPE da gettare nel mezzo di detto lavoro? –

Inoltre, è possibile generare un'eccezione con almeno un messaggio significativo per l'utente (almeno molto meglio di una NullPointerException) parametro –

null non sempre porta a NPE immediato. Ad esempio, può essere messo in un campo o raccolta e portare a bachi difficili da investigare –

Alcune ragioni sono:

Impedisce codice venga eseguito prima della prima volta viene de-reference la variabile (che potrebbe essere nullo).
È possibile avere messaggi di errore personalizzati, come "myVar era nullo, non posso procedere oltre" o qualsiasi messaggio pertinente che risulti migliore nei log e più facilmente rintracciabile. Un normale NPE sarebbe meno leggibile nei log.
La leggibilità del codice è migliore (probabilmente) perché un programmatore che legge questo codice si renderà immediatamente conto che questi valori non sono nulli.

In fin dei conti è una questione di gusti IMO. Ho visto programmi che sono intrinsecamente sicuri e non richiedono alcuna pre-condizione.

fonte

2015-01-22 19:19:42

Nessuno deve sottovalutare il valore dei messaggi di errore personalizzati. – biziclop

Aggiunta una domanda di follow-up basata sulle risposte. Ribadendo la domanda qui: se ci sono buone ragioni, allora gli sviluppatori non dovrebbero usare le librerie per il controllo null su tutti i metodi? – Glide

In generale, solo i metodi che verranno utilizzati "esternamente" richiedono i controlli degli argomenti. Una volta dentro il codice che controlli, specialmente i metodi privati, puoi spesso dimostrare a te stesso che gli argomenti devono essere non nulli (e ovviamente corretti in altri modi pertinenti). La mia regola generale è che qualsiasi metodo o costruttore pubblico ottiene sempre il controllo degli argomenti. – isomeme

Ci sono vari motivi. Uno dei più grandi, come menzionato nei commenti, è di fare il check-up in anticipo prima che il lavoro venga svolto. Inoltre, non è insolito che un metodo abbia un percorso di codice in cui un parametro specifico non viene mai dereferenziato, nel qual caso senza un controllo anticipato, a volte le chiamate non valide al metodo potrebbero non produrre un'eccezione. L'obiettivo è quello di assicurare che il sempre generi un'eccezione in modo che il bug venga intercettato immediatamente. Detto questo, non necessariamente uso checkNotNull se ho intenzione di trasferire immediatamente il parametro sulla riga successiva o qualcosa del genere.

C'è anche il caso dei costruttori, dove si vuole checkNotNull prima di assegnare un parametro a un campo, ma non penso che sia di questo che stai parlando dato che stai parlando di metodi in cui verrà usato il parametro Comunque.

fonte

2015-01-22 19:17:41 ColinD

Uno dei miei principi software preferiti è "Fail early, fail loud". Catturare e riportare una brutta argomentazione al più presto rende la diagnosi e il debug molto più facile. – isomeme

In che modo l'utilizzo delle librerie controlla i valori null meglio di NPE?

risposta

Problemi correlati