Skip to main content

checking for null- how paranoid are you?

3 replies [Last post]
swv
Offline
Joined: 2007-05-28
Points: 0

How paranoid is everyone in checking for null?

For instance:

I have a program in which :

Any way null could be submitted as a member during object construction is checked for by a sentinel.

Contractually, consumers are obligated not to change the value of any object they get from the library (a requirement that makes sense in the given context which I won't go into).

Unmodifiable Collections are used throughout, but access to the individual objects is still possible, so contract ignoring developers could set an object to null- there's not way to stop them (and deep copies to objects accessible to consumers is not applicable, again you're spared the details)..

All entrance of nulls into the program from external libraries is checked- trouble can only come from consumers not following "the rules"

So given the above, how paranoid are you in checking for null? Any null found would necessarily result in an IllegalStateException and an end to the program.

Opinions solicited.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
swv
Offline
Joined: 2007-05-28
Points: 0

Just as an update, I check every parameter that ought not to be null, and also I enforce boundaries on numerical parameters if I can ascertain what they ought (not) to be as I am coding. This is really very helpful, basically because for the reason you numbered 3- bust bad things as early as possible.

I do also recommend the numerical parameter checks. For instance, coordinates Swing hands you (MouseEvent.getPoint()) can be negative. I never knew this, despite years playing on the Swing. I found out when I disallowed negative values and my code threw. Of course, the rest of my code only made sense if the values were non-negative, so i saved myself some serious debugging time and learned something. The thing is, that's ONE place where I was iffy about needing to check- after all, Swing is not going to hand be bum values, right?

Well, Swing didn't hand me bum values, but it did hand me something I *assumed* would be bum values.

So there you go!

p_a_harvey
Offline
Joined: 2008-02-25
Points: 0

IllegalStateException and IllegalArgumentException are not significantly different from a NullPointerException. They are all direct extensions of RuntimeException, and will (most of the time) be caught by the same exception handlers. My preference, for performance reasons, has been this:
1. If a null won't cause any failures, then don't bother checking.
2. If a null would cause an immediate NPE, then don't bother checking - let it throw the NPE.
3. If a null would cause an NPE much later in your code, then check and throw an IAE.

For example, this helper function will throw a NPE immediately if you give a null input. Just let that happen:

[code]
public static double getMaximum(double[] array) {
double result = -Double.MAX_VALUE;
for (double value : array)
if (value > result)
result = value;
return result;
}
[/code]

However, this helper class should check the argument in its constructor as the NPE would occur only when you (at some later stage) call the getMaximum() method:

[code]
public class DoubleArrayHelper {
private double[] array;

public DoubleArrayHelper(double[] array) {
if (array == null)
throw new IllegalArgumentException("array must not be null");
this.array = array;
}

public double getMaximum() {
double result = -Double.MAX_VALUE;
for (double value : array)
if (value > result)
result = value;
return result;
}
}
[/code]

swv
Offline
Joined: 2007-05-28
Points: 0

So do you leave the null checking in your shipping code? In my case, the null (the ones I check for) would be a logical contradiction in the model and the program should end and then CSI-ed.