Catching null pointer exceptions

Question

I'm asking this mainly about Java, but I guess it applies to a whole host of languages.

Consider,

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

and

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

Are both these code blocks essentially the same? Is there any reason to choose the second approach? Of course, it would be better if myVariable was never null, but it seems that the best way to check for it is to do a simple if-statement.

Solution 1

From my stance, I'm hesitant to consider these two code blocks equivalent in intent. Sure, they go through the same error handling, but that's a developer's decision more than anything else.

To me, the if is testing to see if a value can be used, and if it can't, it's working around the issue. The try...catch block is assuming the value is valid, and if it isn't, it falls through to work around the aberrant behavior.

Exceptions should primarly be considered when aberrant, program-breaking code occurs (divide-by-zero, etc).

Solution 2

No, those code blocks are not the same at all.

In the first code block, you are checking if myVariable is null, and you are doing it at only one point in time. Later on, myVariable may become null and eventually throw a NullPointerException. If this happens, the second code snippet will catch the exception, but the first will not.

Furthermore, the second code snippet will catch NullPointerExceptions that may be thrown from anywhere in the call stack resulting from the carryOn(myVariable) call. This is terrible; you are swallowing an exception operating under the assumption that a particular variable is null when it may be something else entirely.

Use the first code snippet.

Solution 3

You only use exceptions for exceptional occurrences. Go with the first block of code, not the second.

Solution 4

Well, by itself, carryOn(MyVariable); won't ever throw a NPE, unless something else within carryOn is referencing a method or property call on a null instance.

Catching exceptions is more computationally expensive than first checking for it, as the generation of an exception requires a stack trace to be generated, etc.

I'd argue that it results in "cleaner" code as well.

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

View more solutions

Comments

[Etienne de Martel]

NullPointerExceptions should be consider programmer errors. Do not catch them. Make sure they never get thrown.

[cheeken]

One parting thought. If you are ever catching any runtime exception (like NullPointerException), you are probably doing something wrong. It is extremely difficult to determine programmatically where such exceptions come from, so it is extremely difficult to handle them properly.