aturetsky
asked on
best practices pertaining to NullPointerException
Any thoughts on best practices pertaining to NullPointerException handling...
Should all methods make it their business to be null-safe in order to be robust and invokable by any future client code that may feed it null input OR is it better to not trash up the code and to just always make sure that there's a code layer (such as validation) that handles null input and to allow the rest of the code to not handle null input.
It has become a point of contention on our team, so I decided to turn this matter over to you, experts.
Should all methods make it their business to be null-safe in order to be robust and invokable by any future client code that may feed it null input OR is it better to not trash up the code and to just always make sure that there's a code layer (such as validation) that handles null input and to allow the rest of the code to not handle null input.
It has become a point of contention on our team, so I decided to turn this matter over to you, experts.
ASKER
thanks for your vote, Autogard,
what does everyone else think?
what does everyone else think?
You should JUNIT test all critical code to see that null-pointer cases
are and REMAIN handled correctly.
Every constructor and setter should be prepared for bad data (from others).
;JOOP!
are and REMAIN handled correctly.
Every constructor and setter should be prepared for bad data (from others).
;JOOP!
ASKER
so can you then ever overdo it on null-checking?
is there ever a wrong time/place to do be doing null-checking
is there ever a wrong time/place to do be doing null-checking
I would think only if your data can't possibly be null -- which it pretty much always can, or if having a null value can't hurt you at all.
I'm guessing you are on the side of the vote of too much null-checking being a bad thing? ;)
I'm guessing you are on the side of the vote of too much null-checking being a bad thing? ;)
ASKER
hmm, sounds pretty unequivocal
any devil advocates here?
any devil advocates here?
ASKER
in other words, are there any cons, at all, whatsoever, to null-checking?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>> http://hoskinator.blogspot.com/ -- "Where should you check for NullPointerExceptions"
that's a very helpful post
>> http://leepoint.net/notes-java/flow/assertions/assertions.html -- "Check for "impossible" conditions, not bad input"
very interesting article, I've got to try assertions. Can you elaborate on what you take out of this one as it pertains to null pointer exceptions?
that's a very helpful post
>> http://leepoint.net/notes-java/flow/assertions/assertions.html -- "Check for "impossible" conditions, not bad input"
very interesting article, I've got to try assertions. Can you elaborate on what you take out of this one as it pertains to null pointer exceptions?
I thought that first article was more helpful as well.
From the second article, about all that I saw that was very interesting (from a devil's advocate point of view as you suggested) was "you must decide if the extra code is worth the better error diagnostic. In many cases the answer is "no"." -- but I'm not sure this relates exactly to what you are doing with null checking as the article is mostly about assertions, which they say to use in spots where execution should never occur. Null-checking is used differently than assertions.
From the second article, about all that I saw that was very interesting (from a devil's advocate point of view as you suggested) was "you must decide if the extra code is worth the better error diagnostic. In many cases the answer is "no"." -- but I'm not sure this relates exactly to what you are doing with null checking as the article is mostly about assertions, which they say to use in spots where execution should never occur. Null-checking is used differently than assertions.
ASKER
so, speaking of the case against null checking
I mean wouldn't it be correct to say that null checking should not be used to check for programmer errors in the client code - I mean if the client code is buggy and fails to properly handle null input using invalid argument exceptions or what not, and instead passes nulls down the chain, then let it crash during development time and fix it.
No?
I mean wouldn't it be correct to say that null checking should not be used to check for programmer errors in the client code - I mean if the client code is buggy and fails to properly handle null input using invalid argument exceptions or what not, and instead passes nulls down the chain, then let it crash during development time and fix it.
No?
My main purpose for null-checking in the software would be to check user input more than anything.
As far as checking programming errors, yeah that to me is up to the testing of the software to handle. As sciuriware mentioned, JUnit is a great way to do this. Make sure your code can handle user stupidity and input and make sure your testers/testing can eliminate programmer stupidity and errors :)
That said, I still have an itch to say that you should make sure funky inputs don't crash your code even in a production environment -- users have funky ways of getting input there. But I think what those other articles tried to explain is that it is ok to check for that at higher levels, which a layer or wrapper that is not necessarily connected to the lower code can't always guarantee. Hmm, maybe I'm too paranoid though. :)
As far as checking programming errors, yeah that to me is up to the testing of the software to handle. As sciuriware mentioned, JUnit is a great way to do this. Make sure your code can handle user stupidity and input and make sure your testers/testing can eliminate programmer stupidity and errors :)
That said, I still have an itch to say that you should make sure funky inputs don't crash your code even in a production environment -- users have funky ways of getting input there. But I think what those other articles tried to explain is that it is ok to check for that at higher levels, which a layer or wrapper that is not necessarily connected to the lower code can't always guarantee. Hmm, maybe I'm too paranoid though. :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The best place to start is method-arguments. If you don't expect any method-arguments to be null, then check them:
public void someMethod ( String a, String b, .... )
throws MyException
{
if ( a == null || b == null || .... )
throw MyException ( "Parameter(s) cannot be null. " ) ;
In your code, just make sure that you check for null before calling any method, like:
String c = getSomeValue () ;
if ( c != null )
{
// process 'c' by calling its methods, etc
}
}
Some cases will already be handled by the compiler because it will not allow you to use uninitialized variables anyway. You just need to check for the ones whose values come from some other method(s)/ block(s).
public void someMethod ( String a, String b, .... )
throws MyException
{
if ( a == null || b == null || .... )
throw MyException ( "Parameter(s) cannot be null. " ) ;
In your code, just make sure that you check for null before calling any method, like:
String c = getSomeValue () ;
if ( c != null )
{
// process 'c' by calling its methods, etc
}
}
Some cases will already be handled by the compiler because it will not allow you to use uninitialized variables anyway. You just need to check for the ones whose values come from some other method(s)/ block(s).
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
jim_cakalic - thanks for your thorough input - the rule is somewhat ambiguous but it makes sense
mayankeagle - so you're basically all for null checking, right?
fffej78 - great input - can you elaborate on the null object pattern - I read those two links but couldn't quite picture how exactly it would be used in the real world based on their examples; also, as far as the http://cdsmith.twu.net/professional/java/pontifications/nonnull.html goes - isn't that just a proposal, not something that already exists?
mayankeagle - so you're basically all for null checking, right?
fffej78 - great input - can you elaborate on the null object pattern - I read those two links but couldn't quite picture how exactly it would be used in the real world based on their examples; also, as far as the http://cdsmith.twu.net/professional/java/pontifications/nonnull.html goes - isn't that just a proposal, not something that already exists?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> so you're basically all for null checking, right
Right.
Right.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks to all your helpful input. I will keep referring to your recommendations as we implement a new null handling policy.
Also I don't think adding NullPointerException handling really does "trash up the code" at all. If safety is an important factor in your code (which I hope it is) then I think it's worth it. Having both a layer and checking in the code, I think is a good idea.
That's my opinion. :)