Re: Overloaded Methods called with null
- From: "John C. Bollinger" <jobollin@xxxxxxxxxxx>
- Date: Thu, 29 Dec 2005 23:21:01 -0500
ricky.clarkson@xxxxxxxxx wrote:
Chris Smith,
That page must be some kind of joke.
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.
Is it now considered acceptable to modify a public interface to be less capable
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.
And you're now not allowed to create arrays of any length that's not known at compile-time?
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.
-- John Bollinger jobollin@xxxxxxxxxxx .
- References:
- Overloaded Methods called with null
- From: Oliver Brausch
- Re: Overloaded Methods called with null
- From: Roedy Green
- Re: Overloaded Methods called with null
- From: Roedy Green
- Re: Overloaded Methods called with null
- From: Chris Smith
- Re: Overloaded Methods called with null
- From: Roedy Green
- Re: Overloaded Methods called with null
- From: ricky.clarkson@xxxxxxxxx
- Re: Overloaded Methods called with null
- From: Chris Smith
- Re: Overloaded Methods called with null
- From: ricky.clarkson@xxxxxxxxx
- Overloaded Methods called with null
- Prev by Date: Compiling Java file to .NET managed code or vice versa?
- Next by Date: Re: Compiling Java file to .NET managed code or vice versa?
- Previous by thread: Re: Overloaded Methods called with null
- Next by thread: Re: Overloaded Methods called with null
- Index(es):
Relevant Pages
|
