Overloaded Methods called with null

[John C. Bollinger]

Chris Smith,




More of a bin for some ideas I had late one night. I've modified the
code sample at the top and I think it is more accurate now.




That depends. The rules are not for general programming, per se, but
for avoiding NullPointerExceptions. New programmers find the
NullPointerException quite obtuse, and are used to error messages at
runtime being not their fault, from the rubbish software that they use
daily. This isn't conjecture, this is my observation.

Where are all these faultless new programmers coming from? Many moons
ago when I was a new programmer, I tended to think that any error
message at runtime was *surely* my fault. Perhaps I'm strange that way,
but doesn't it stand to reason that if I don't know very well what I'm
doing then problems are more likely to arise from me not doing it
correctly than from any other source? For that matter, I'm still the
most likely cause of runtime errors in my programs, even now that I
mostly do know what I'm doing.

NullPointerExceptions are obtuse to the Java newbie, I agree, but the
solution is to educate him about the cause, not to saddle him with a
bunch of code-convoluting rules. Those given in the Wikibooks article
aren't even 100% reliable. (Nulls can enter the program through various
methods' return values, for instance. Also, though its obvious, if one
doesn't want to see NPEs then one shouldn't explicitly throw any.) What
is the value of teaching rules that are not suitable for general
programming?

I think the article is focused incorrectly. Rather than presenting
coding rules that are likely to be at least as opaque as the NPEs
themselves, why not explicitly educate about where null values come
from? That's where all your rules seem to have come from anyway.

Again, if you're interested in preventing NullPointerExceptions, then
this is a rule worth following.

I disagree, but I do find the comment to representative of the article's
approach. The problem is not with using arrays in general, nor with
creating them via the "new Type[count]" syntax. It is with attempting
to dereference an array element that has not been assigned a non-null
value. Using Lists instead of arrays and initializing arrays with
explicit initializers do reduce the chance of NPEs vs. "new
Type[count]", but sometimes neither of the former gives you what you
want. A better rule here would be "Initialize All Array Elements",
where you could discuss that the elements are initialized to
null if no array initializer is used. "Consider using Lists instead of
Arrays" would be potentially useful as a separate rule.