I was mentioning iPhone more from usability perspective, to compare to language used by developers.

Mmmmm, £1.40 hot dog

The iPhone 4 isn’t a good example this time . From what I’m hearing from other web devs the amount of hardware and software issues are higher from a first release.

Plus don’t disrespect a £1.40 Hot Dog Menu. Next time ask for a hot dog with a cup of beans and be amazed!

So what if my method contract instead is: I’ll return you a proper object, or throw a checked exception (heh, I guess it would only work in Java).

What you get out of that is the same as above, no problems with null. You are forced to deal with the exception, and importantly, the exception can carry much better failure information than your NullObjects or Maybe’s.

What do you think?

The Nullable struct in .NET is really useful but only works with value types, since classes are nullable as they are.

One thing to keep in mind though is that Empty objects are actual values, null represents the absence of a value. String.Empty vs a null string is a good example of this.

One easy thing to do is turn those null checks into booleans first, to make it more descriptive for the next person who works with the code:

Instead of:
if (serverResponse == null)
{
// DoStuff
}

Write:
bool serverNotAvailable = (serverResponse == null);
if (serverNotAvailable)
{
// DoStuff
}

if (value != null)

different from

if (value.HasValue)

If you really like the syntax for the latter, come up with an extension method that does the same thing.

My first option (which you don’t have on your list) is to throw an exception. In practice, if I always ask a valid request, I’ll never throw. When I do throw, it’s because I ran into a problem that I hadn’t previously expected, and now I can decide which pattern best fits (if any)

I try to defer making a decision on how to deal with it until I know just how much of a problem it is