Java: check for null or allow exception handling

Question

I'm wondering about the cost of using a try/exception to handle nulls compared to using an if statement to check for nulls first.

To provide more information. There's a > 50% chance of getting nulls, because in this app. it is common to have a null if no data has been entered... so to attempt a calculation using a null is commonplace.

This being said, would it improve performance if I use an if statement to check for null first before calculation and just not attempt the calculation in the first place, or is less expensive to just let the exception be thrown and handle it?

thanks for any suggestions :-)

Thanks for great thought provoking feedback! Here's a PSEUDOcode example to clarify the original question:

BigDecimal value1 = null //assume value1 came from DB as null
BigDecimal divisor = new BigDecimal("2.0");

try{
    if(value1 != null){ //does this enhance performance?... >50% chance that value1 WILL be null
        value1.divide(divisor);
    }
}
catch (Exception e){
    //process, log etc. the exception
    //do this EVERYTIME I get null... or use an if statement
    //to capture other exceptions.
}

Answer 1

Try and catch are close to "free" but throws can be very expensive. Typically VM creators do not optimize exception paths since, well, they are exceptional (supposed to be rare).

NullPointerException indicates a programmer mistake (RuntimeException) and should not be caught. Instead of catching the NullPointerException you should fix your code to cause the exception not to be thrown in the first place.

Worse yet, if you catch the NullPointerException and a different part of the calculation code throws NullPointerException than the one you expect to throw it you have now masked a bug.

To fully answer your question, I would implement it one way, profile it, and then implement it the other way and profile it... then I would only use the one with the if statement that avoids throwing the NullPointerException regardless of which is faster simply because of the point above.

Answer 2

I'd recommend checking for null and not doing the calculation rather than throwing an exception.

An exception should be "exceptional" and rare, not a way to manage flow of control.

I'd also suggest that you establish a contract with your clients regarding input parameters. If nulls are allowed spell it out; if they're not, make it clear what should be passed, default values, and what you promise to return if a null value is passed.