Is returning null bad design? [closed]

Question

The rationale behind not returning null is that you do not have to check for it and hence your code does not need to follow a different path based on the return value. You might want to check out the Null Object Pattern which provides more information on this.

For example, if I were to define a method in Java that returned a Collection I would typically prefer to return an empty collection (i.e. Collections.emptyList()) rather than null as it means my client code is cleaner; e.g.

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

... which is cleaner than:

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

Here's the reason.

In Clean Code by Robert Martin he writes that returning null is bad design when you can instead return, say, empty array. Since expected result is an array, why not? It'll enable you to iterate over result without any extra conditions. If it's an integer, maybe 0 will suffice, if it's a hash, empty hash. etc.

The premise is to not force calling code to immediately handle issues. Calling code may not want to concern itself with them. That's also why in many cases exceptions is better than nil.

Good uses of returning null:

• If null is a valid functional result, for example: FindFirstObjectThatNeedsProcessing() can return null if not found and the caller should check accordingly.

Bad uses: Trying to replace or hide exceptional situations such as:

• catch(...) and return null
• API dependency initialization failed
• Out of disk space
• Invalid input parameters (programming error, inputs must be sanitized by the caller)
• etc

In those cases throwing an exception is more adequate since:

• A null return value provides no meaningful error info
• The immediate caller most likely cannot handle the error condition
• There is no guarantee that the caller is checking for null results

However, Exceptions should not be used to handle normal program operation conditions such as:

• Invalid username/password (or any user-provided inputs)
• Breaking loops or as non-local gotos

Yes, returning NULL is a terrible design, in object-oriented world. In a nutshell, NULL usage leads to:

• ad-hoc error handling (instead of exceptions)
• ambiguous semantic
• slow instead of fast failing
• computer thinking instead of object thinking
• mutable and incomplete objects

Check this blog post for a detailed explanation: http://www.yegor256.com/2014/05/13/why-null-is-bad.html. More in my book Elegant Objects, Section 4.1.

Who says this is bad design?

Checking for nulls is a common practice, even encouraged, otherwise you run the risk of NullReferenceExceptions everywhere. Its better to handle the error gracefully than throw exceptions when you don't need to.

Based on what you've said so far, I think there's not enough information.

Returning null from a CreateWidget()method seems bad.

Returning null from a FindFooInBar() method seems fine.