Una domanda molto basilare sull'opportunità di controllare null e lanciare NPE? [duplicare]

Question

Una domanda molto basilare sull'opportunità di controllare null e lanciare NPE? [duplicare]

#1 da (9 voti)
#2 da (3 voti)
#3 da (-1 voti)

2

Considera il metodo seguente:

public void operationOnList(List<String> list) {
    list.add(1);
}

È ovvio che se l'elenco è nullo, questo metodo genererà una NullPointerException.

La mia domanda è: dovrei invece verificare esplicitamente null in questo caso?

public void operationOnList(List<String> list) {
    if (list == null) throw new NullPointerException("some message")
    list.add(1);
}

Su uno ho potuto aggiungere un messaggio qui, ma cosa succede se non sono davvero preoccupato per il messaggio? Mi aiuta a salvare una ramificazione non necessaria nel codice.

Quindi quale è preferibile e quale è più efficiente?

EDIT - non è un duplicato: nel mio caso, il metodo genererà una NullPointerException se si passa un valore Null in ENTRAMBI i casi precedenti. Non desidero o devo gestire l'eccezione e risolverlo nella funzione.

Quello che sto chiedendo è che dovrei controllare nullo esplicitamente (aggiungendo inutile se condizione o dovrei lasciare che l'NPE si verifichi quando viene usata quella variabile?

Modifica: -------------------------------------

Alcuni pensieri nel tempo:

Se il metodo è esposto al client, ovvero fa parte di alcune API, è consigliabile controllare il prima possibile per verificare l'eccezione e lanciare un NPE con un buon messaggio. Il motivo è che se l'NPE viene lanciato dall'interno, viene stampata una brutta traccia di stack e l'utente potrebbe non sapere immediatamente quale metodo è il colpevole.

java exceptions null

posta rents 23.05.2016 - 11:30

fonte

3 risposte

Leggi altre domande sui tag java exceptions null

Perché le variabili in Python sono diverse dagli altri linguaggi di programmazione? [chiuso] Perché i motori audio non elaborano l'audio in modo più realistico?

score 9 · Answer 1

Preferisco NON sporcare il mio codice con assegni nulli, perché fondamentalmente è solo confusione. Sì, a volte è necessario, come quando si legge l'input dell'utente o si opera ai limiti dell'applicazione, si ricevono elementi da servizi di terze parti ecc.

Ma mantieni la tua logica di business pulita. Se un parametro non può essere nullo, considera attendibile che non sia nullo. In effetti, dovresti cercare di evitare o del tutto vietare nulla nel tuo codice di produzione. Se non si passa mai nulla, non si otterranno mai gli NPE. Ciò consente anche di evitare l'avvio di alcune dipendenze nei test che non sono rilevanti per il test corrente.

Il codice che controlla in modo difensivo null dappertutto è più difficile da leggere e più difficile da modificare, rende il codice più rigido e più difficile da testare ed è un modo davvero inefficiente di trovare bug.

Concentrati sull'assicurarti che i valori che entrano nel tuo sistema vengano convalidati e "purificati" e mantengano il tuo nucleo pulito.

score 3 · Answer 2

Normalmente eseguo questi tipi di controlli ai limiti a gruppi di componenti, ad es. per i consumatori di terze parti. Se asserisci gli argomenti in entrata per nullità (e qualsiasi altra cosa), i tuoi clienti riceveranno un chiaro messaggio su come stanno abusando della tua API, e da quel punto in poi puoi essere ragionevolmente al sicuro nell'assumere che i dati di input siano in uno stato buono e conosciuto. All'interno dei componenti interni non eseguirò normalmente tali controlli.

In quanto sopra, potrei preferire un IllegalArgumentException , poiché è ciò che viene fornito.

I nulli in genere sono un problema, dal momento che ogni riferimento può essere nullo e non si conoscono quelli che sono "validi" essendo nulli, vale a dire che mancano i dati e ciò che deve essere soddisfatto. Se hai veramente a che fare con i dati facoltativi , la tua API per i tuoi clienti e il tuo codice sottostante saranno più chiari utilizzando Optional . Vedi qui per ulteriori dettagli .

score -1 · Answer 3

IMHO, se è per una libreria, penso che sia corretto lanciare un'eccezione in modo che il consumatore della libreria sappia che qualcosa deve essere cambiato nell'implementazione del metodo.

Ma se è usato per la "produzione finale" che interagirà con l'utente, penso di mostrare un messaggio che dice loro che sta succedendo qualcosa di sbagliato. Successivamente l'app dovrebbe eseguire qualsiasi azione necessaria in base all'errore.