Catch delle eccezioni del puntatore nullo

Question

Sto chiedendo questo a proposito di Java, ma suppongo che si adatti a un'intera schiera di lingue.

Si consideri,

if(myVariable==null){ 
     doSomethingAboutIt(); 
} 
else carryOn(myVariable); 

e

try{ 
    carryOn(MyVariable); 
}catch(NullPointerException e){ 
     doSOmethingAboutIt();} 

Sono entrambi questi blocchi di codice essenzialmente la stessa? C'è qualche ragione per scegliere il secondo approccio? Chiaramente sarebbe bette rif myVariable non è mai stato nullo, ma sembra che il modo migliore per controllarlo sia di fare una semplice istruzione if.

Answer 1

Dal mio punto di vista, sono riluttante a considerare questi due blocchi di codice equivalenti nell'intento. Certo, subiscono la stessa gestione degli errori, ma questa è la decisione di uno sviluppatore più che altro.

Per me, lo if è test per vedere se è possibile utilizzare un valore e, se non è possibile, si sta lavorando attorno al problema. Il blocco try...catch è supponendo che il valore sia valido e, in caso contrario, ricade per aggirare il comportamento aberranti.

Le eccezioni devono essere prese in considerazione in primo luogo quando si verifica un codice anomalo di interruzione del programma (divisione per zero, ecc.).

Answer 2

Beh, di per sé, carryOn(MyVariable); non getterà mai un NPE, a meno che qualcos'altro all'interno di carryOn fa riferimento a un metodo o una chiamata di proprietà su un'istanza nulla.

Facendo eccezioni è più computazionalmente costoso di prima verifica per esso, come la generazione di un'eccezione richiede una traccia dello stack da generare, ecc

direi che si traduce in codice "pulito", così .

Consulta anche: - Java try/catch performance, is it recommended to keep what is inside the try clause to a minimum? - Try Catch Performance Java

Answer 3

di utilizzare solo le eccezioni per eventi eccezionali. Vai con il primo blocco di codice, non il secondo.

Answer 4

Il primo approccio è migliore rispetto all'eccezione perché c'è una penalità legata alle prestazioni. L'approccio migliore a mio avviso è applicare Null Object pattern. La libreria Guava fornisce la classe Optional a cui puoi fare leva invece di crearne una tua.

Answer 5

No, quei blocchi di codice non sono affatto uguali.

Nel primo blocco di codice, si sta verificando se myVariable è null e lo si sta facendo in un solo punto nel tempo. Successivamente, myVariable potrebbe diventare null e infine inserire uno NullPointerException. Se ciò accade, il secondo snippet di codice prenderà l'eccezione, ma il primo no.

Inoltre, il secondo snippet di codice catturerà NullPointerExceptions che potrebbe essere generato da qualsiasi punto dello stack di chiamate risultante dalla chiamata carryOn(myVariable). Questo è terribile; stai ingoiando un'eccezione operando nel presupposto che una particolare variabile sia null quando potrebbe essere qualcos'altro.

Utilizzare il primo snippet di codice.