Dealing with nulls
This is very non-specific question, I'm sorry. Still, it's something that comes up from time to time when I write java.
Basically, suppose an object takes a list of something in it's constructor. The object expects that that list of something containsno nulls - ie it calls a method on each member of the list, and a NPe would be thrown if a null was encountered.
Obviously, depending on the circumstances, nulls might have a significance, and a class would allow and deal with them in it's own way. In the case where this is not how a class functions, it would be nice to make this as explicit at possible; there's something quite irking about a plain 'NullPointerException at blahblahblah' sitting on screen, with no explanation. If it was user error, where someone thought that they could supply a list containing nulls when they couldn't, it would be nice to disabuse them of this notion, instead of giving an unlabeled error.
My question is this: knowing in advance that nulls are not acceptable to the class, when should this become apparent?
a.) When the object is constructed, throw a NPe with a nice explanation such as 'this object does accept nulls for such-and-such an argument'? This might involve iterating through an entire list beforehand; if it's a big list then this is a big waste of time.
b.) When a nullpointer exception may be caused, ensure it is encased with a try/catch, then rethrow the exception with an explanation. The drawback to this is obvious; a ton of duplicated code could well be required
c.) Do nothing; do not catch the exception and just leave the recipient of the error message in the dark (if the error is uncaught)
Not a biggie, just wondering what others of you would do.
[1783 byte] By [
fragorla] at [2007-10-2 10:31:03]
The first method is not practical at all, programmers should know how to construct their list before passing it to other methods
The second method seems to cause too much typing, try/catch and rethrow NullPointerException with nicer description doesn't seem practical as well.
The third method... dark? In your top level method, you catch root exception and notify user about fatal exception and log the NullPointerException anyway. Sounds logical
> a.) When the object is constructed, throw a NPe with
> a nice explanation such as 'this object does accept
> nulls for such-and-such an argument'? This might
> involve iterating through an entire list beforehand;
> if it's a big list then this is a big waste of time.
That depends on the situation. If it's absolutely crucial there can't be nulls then check it. If you have performance problems later profile and see if it's actually a problem. If you can handle the nulls yourself then consider that.
> b.) When a nullpointer exception may be caused,
> ensure it is encased with a try/catch, then rethrow
> the exception with an explanation. The drawback to
> this is obvious; a ton of duplicated code could well
> be required
Let it occur. Once they look at the documentation they'll see exactly why a NullPointerException may be thrown from your method and have their reason.
> c.) Do nothing; do not catch the exception and just
> leave the recipient of the error message in the dark
> (if the error is uncaught)
They're only in the dark if you don't document or they don't read. In the first case, document it. In the second case, they can go to hell.
> Not a biggie, just wondering what others of you would
> do.
1. Document it well.
2. Throw a NullPointerException when the situation is encountered or let it propogate up.
3. See #1 about documenting #2.
I just use the same guidelines as any other exception. A good read is Joshua Bloch's item in his book about exceptions.
>> Ok, cheers. And I will definitely take a look at that
>> article on exceptions.
>The book is Effective Java and there's an item about exceptions, it's not the >whole book.
Ok, I see. I just read the sample chapters which are available online. Good stuff
