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.

`NullPointerException`s should be consider programmer errors. Do not catch them. Make sure they never get thrown. — Etienne de Martel, Jan 23 '12 at 00:21

score 10 · Accepted Answer · answered Jan 23 '12 at 00:22

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).

score 5 · Answer 2 · answered Jan 23 '12 at 00:25

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.

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. — cheeken, Jan 23 '12 at 00:28

score 3 · Answer 3 · answered Jan 23 '12 at 00:22

3

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

answered Jan 23 '12 at 00:22

Hovercraft Full Of Eels

283,665
25
256
373

score 2 · Answer 4 · edited May 23 '17 at 12:09

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

score 0 · Answer 5 · answered Jan 23 '12 at 00:23

The first approach is better than catching exception because there is some performance penalty incurred. The best approach in my opinion is to apply Null Object pattern. Guava library provides Optional class to that you can leverage instead of creating your own.

Catching null pointer exceptions

5 Answers5