Re: Checking for null parameter
On Mon, 9 Jun 2008, Lew wrote:
Lew wrote:
A method must be coded to handle any input that can be sent to it.
Otherwise it will break when it gets the wrong input.
Tom Anderson wrote:
This is very silly advice.
Calling it "silly" is criminally irresponsible; someone might believe you.
A risk which, happily, does not exist concerning your advice that every
method null-check its parameters.
What's the matter, is it too hard to copy-and-paste a try-catch block?
Around *every* *single* *method* (or code block, or whatever granularity
you fancy)? Yes. Yes it is.
You must put try-catch blocks somewhere where exceptions can occur, or your
program will crash.
This is the crux of it - some methods do need hardening against duff
parameters, like nulls, NaNs, out-of-range integers, objects that are
invalid in more subtle ways, etc, but not all.
Wrong. All methods must be able to handle any input that they can receive,
otherwise your program will crash.
This all hinges on what you mean by 'can'. Consider this program:
public class LewIsWrong {
public static void printLength(String str) {
System.out.println(str.length()) ;
}
public static void main(String[] args) {
printLength("Hello, world!") ;
}
}
Would you say that an exception can occur in the body of printLine? Would
you say that printLine can receive a null as input?
If so, then this program does not meet your requirements, since it does
nothing about handling a null in printLength. And yet, it does not crash.
If not, then actually, we're in agreement.
This is a trivial example, and a matter of semantics, but it is not a
frivolous point. There can be as many places as you like in your program
where an exception, crash, etc could occur in certain circumstances, but
as long that those circumstances never arise, the program will not crash.
One way of preventing crashes is to remove the places where crashes can
occur; another is to stop them being triggered. The former sounds better
in theory, because it should be more 'robust', but it doesn't work in
practice - every method, no matter how trivial, would need to check its
arguments, and there would be as much argument-checking code as functional
code. Certainly, there are times when armouring a method is a good idea -
when it's an entry point to a package, or when it does something
potentially dangerous. It's simply not good engineering to do it in every
single public method, though.
I'm also curious about what you would suggest doing in printLength that
would prevent a crash when a null is passed in. Presumably, i test for
null, or catch the NullPointerException - but what do i do then? Skip the
printing? Print 0? Print an error message? I'd say that the program is
then behaving incorrectly, which is worse than crashing. Should it throw
an unchecked exception? Then it merely crashes in a different way. Should
it throw a checked exception? What could the calling code do with that
that isn't ultimately also crashing?
I don't know about you, but all the customers I've had consider letting
a program crash to be bad.
I'm with you here. I do not endorse programs crashing. I wish to make this
clear.
You say all public methods, but i [sic] think that's overkill. Firstly,
it only needs to be on exported methods - methods that you expect
outside code to call; the
Right, I did say this applied to public methods.
main entry points to the component or package or whatever. If outside
code wants to call your internal methods with duff arguments, fine, let
it handle the consequences. Secondly, i'm [sic] generally quite happy
to have
The consequences which are coded into the API and documented in its Javadocs,
yes.
code screws up when given a null, as long as it's clear that i [sic]
shouldn't pass a null. That again hands the responsibility for not
passing in a null to the caller.
It's only clear that you shouldn't pass 'null' to an API method if the
method planned for and handles the 'null', say by throwing an NPE,
No.
and tells you so in its Javadocs. Otherwise how would it be clear?
By telling you so in the javadocs.
It would be nice if java [sic] could express a requirement for non-nullity
in the type system. Some type systems forbid nulls from normal variables,
It can - by including a checked exception in the method signature.
No.
tom
--
In-jokes for out-casts