WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.
(See intro for a background and caveats on these coding advice blog entries.)
When a method is supposed to return an object, and it returns "null",
the null is used to convey a number of meanings:
- Empty (when it's supposed to return an array or a list, but the list is empty)
- Can't (when some error happens and an object to be constructed failed; the caller
is now supposed to gracefully handle the error) - Unknown (when a method is supposed to compute some result that it couldn't figure out)
...and probably many more.
Whenever possible, avoid using nulls. There are several better alternatives.
When a method needs to return an array, and you know the array is empty,
don't be lazy and just return null. Perhaps you're not being lazy, but believe
you're being efficient, because by returning null you can communicate empty
to the caller without having to construct an object (the empty array or list).
However, the performance impact is minimal. It's very cheap to construct
short-lived objects in Java - much less thanmalloccost in C.
However, you can use the following pattern if this is going to be frequent:
class Window {
private static final Window[] NO_WINDOWS = new Window[0];
public getActiveWindows() {
if (whatever) {return null;
return NO_WINDOWS;
}
...
}
...
An approach like this has the advantage that you can start simplifying your
own code, since you won't be doing null checks everywhere. If you call thegetActiveWindows()method above, you can simply iterate over
the results directly rather than branching on null first.
When the "null" return value means something like "unknown", it's even
better to use a special marker object. This has a number of advantages.
The intent is more clearly communicated, so the code is easier to read.
The marker object can customize some of its methods such that it reacts
appropriately. This allows you to move some handling code into the object
itself rather than in the client code. (As a simple example, yourtoStringmethod can be written to be more informative.)
The class containing the marker object can also be written to consider
marker objects in a correct way; for example, the rightequals()
semantics can be written.
The above is a bit abstract so let me illustrate with another example. Let's
say we're writing a word processor. We have a Document class, representing a document,
and a Caret class, representing a visual caret (text insertion cursor). The caret
has an associated position in the document, and this is represented by a Position object.
Thus, the caret has the following method:
public Position getPosition();
Sometimes a document doesn't have an associated caret position - for
example, when the document does not have focus. We could simply havegetPosition()return null for this. But that would mean that client
code relying on positions would always need to check for null before calling methods
on the position they receive. Instead, the Position class should have a static
field representing a non-existent position:
class Position {
public static final Position NONE = new Position(xxx);
...
Now, most client code can simply call Position methods without worrying whether
it will be null or not. The Position class itself can be modified such that
various methods handle theNONEcase correctly: not only can
toString() do something like this:
public String toString() {
if (this == NONE) {
return "Position.NONE";
} else {
...
but for example position comparison methods can have special considerations for how
to handle positions where one or more represent the nonexistent position.
Yes, this could be achieved by consistent use of null instead, but it's a lot
less readable, and harder to search.
Null handling has gotten some renewed attention recently. With the advent of
annotations, you can annotate whether a method is expected to return null or not
(e.g. with @notnull).
This allows tools to perform static analysis of your code and find potential
bugs. For example, if you indicate that a method cannot return null, the tool
can obviously flag any "return null" statements within that method (or returning
expressions calling methods that may return null). But they
can also flag code calling this method that unnecessarily check the return value
for null, and more importantly, flag missing return value checks in code calling
methods that may return null.
IntelliJ has added
this feature
already. Looks like it has
been
around
for at least 10 years with lint checkers in C. I look forward to getting this
in my favorite IDE
(why oh why isn't @notnull and @nullable part of the
standard annotations set?)
- but in any case, try to avoid nulls by using
place holder objects where appropriate.
