How to show if a method may return null

Question

After posting this question and reading that one I realized that it is very important to know if a method is supposed to return null, or if this is considered an error condition and an exceptions should be thrown. There also is a nice discussion when to return ‘null’ or throw exception .

I'm writing a method and I already know if I want to return null or throw an exception, what is the best way to express my decision, in other words, to document my contract?

Some ways I can think of:

• Write it down in the specs / the documentation (will anyone read it?)
• Make it part of the method name (as I suggested here)
• assume that every method that throws an exception will not return null, and every one that does 'not' throw might return null.

I'm mainly talking about java, but it might apply to other languages, too: Why is there a formal way to express if exceptions will be thrown (the throws keywords) but no formal way to express if null might be returned?

Why isn't there something like that:

public notnull Object methodWhichCannotReturnNull(int i) throws Exception
{
    return null; // this would lead to a compiler error!
}

Summary and Conclusion

There are many ways to express the contract:

• If your IDE supports it (as IntelliJ), it's best to use an annotation like @NotNull because it is visible to the programmer and can be used for automated compile time checking. There's a plugin for Eclipse to add support for these, but it didn't work for me.
• If these are not an option, use custom Types like Option<T> or NotNull<T>, which add clarity and at least runtime checking.
• In any way, documenting the contract in the JavaDoc never hurts and sometimes even helps.
• Using method names to document the nullability of the return value was not proposed by anyone but me, and though it might be very verbose und not always useful, I still believe sometimes it has its advantages, too.

Answer 1

You could write your own annotation (Java) or attribute (C#) to indicate that the return value might be null. Nothing will automatically check it (although .NET 4.0 will have code contracts for this sort of thing) but it would at least act as documentation.

Answer 2

There's some support for a @Nullable and @NotNull annotation in IntelliJ IDEA. There's also some talk about adding those annotations (or a similar feature) to Java 7. Unfortunately I don't know how far that got or if it's still on track at all.

Answer 3

For Java, one can use the Javadoc description of a method to document the meaning of the returned value, including whether it can be null. As has been mentioned, annotations may also provide assistance here.

On the other hand, I admit that I don't see null as something to be feared. There are situations in which "nobody's home" is a meaningful condition (although the Null Object technique also has real value here).

It is certainly true that attempting a method invocation on a null value will cause an exception. But so will attempting to divide by zero. That doesn't mean that we need to go on a campaign to eliminate zeroes! It just means that we need to understand the contract on a method and do the right thing with the values that it returns.

Answer 4

At all costs, avoid relying on the JavaDocs. People only read them if the signature doesn't appear trivial and self-explanatory (Which is bad to begin with), and these who actually bother to read them are less likely to make a mistake with the nulls since they are currently being more careful.

Answer 5

Indeed: in our framework we have a 'non-null' pointer type, which may be returned to indicate that the method will always return a value.

I see three options:

1. wait for language support to express it (e.g. the C# ?! thing)
2. use Aspect Orientation to build your own language extensions to express it
3. use a custom type to express it
4. (but builds on developer cooperation) use a naming scheme to indicate it

Answer 6

Have you had a look at Spec#?