What should be returned if not null when value cannot be found

Question

Everywhere I read constantly rehashes the idea of "never return nulls" but what should I return if not null in the cases where a value cannot be found?

Take the following method

List<Customer> GetCustomerListByRoleID(Guid RoleID) {}

In this case (and in most plural methods) its easy to simply return an empty List<Customer> if we can't find our value and we're good.

However in the case of a method like

Customer GetCustomerByID(Guid CustomerID) {}

You do not have the luxury of returning an empty array. Infact all you can do is return a New Customer(); but then you have a potentially uninitialized object (which you still need to check for) or null.

So what would be the recommended alternative to returning a null in the singular method?

Answer 1

For the single value case consider the TryGet pattern

bool TryGetCustomerByID(Guid CustomerID, out Customer customer) { }

This clearly expresses the intent that this method can and will fail and makes it much more awkward to ignore the aspect of failure. Dealing with it correctly though produces very readable code.

Customer c;
if (container.TryGetCustomer(id, out c)) {
  ...
} else {
  // Deal with failure
}

Often I like to pair my TryGet APIs with a version that throws for those occasions when the caller knows it must be present else it's a violation of some implicit contract.

Customer GetCustomerByID(Guid id) {
  Customer c;
  if (!TryGetCustomerByID(id, out c)) {
    throw new Exception(...);
  }
  return c;
}

Answer 2

I think it depends whether asking for a customer which doesn't exist should be seen as an error. The two obvious options are:

• Return null
• Throw an exception (CustomerNotFoundException or something like that)

In the case where you're being given a Guid, it feels like there's the clear expectation that that will represent a customer. It's not like it would be normal to try to fetch a customer with a Guid on the offchance that one exists.

You could return a Tuple<Customer, bool> or TryGetCustomer - but to be honest, I think both of those are overly complicated for this situation.

The most important thing is that you document what will happen... in particular, if your code will never return null, state that in the documentation. (Or consider using code contracts to give the same information...)

Answer 3

You couuld define a static Customer object which represents a null customer (i.e. Customer.Name = "NOT_FOUND", and return that object instead of null. Then in the calling method, just compare the returned value with that static customer.

edit: Although I admittedly would rather just return null.

Answer 4

Why retunring a null is discouraged? The idea is that if function's return type is T, you always get one object of type T, while null is definitely not something of type T, not even zero objects of type T.

In the case of getCustomers(), you get a List<Customer> which is 0 to n Customer objects.

In the case of getCustomer() you'd like 0 or 1 Customer objects. In Haskell, you get ADTs and Maybe for that, in Scala, you have case classes and Option. Wha can you use in C#? Well, there's Maybe implementaion in C#, it's really simple inside.

With Maybe<Customer> getCustomer() you're guaranteed not to pass its result as a null value instead of a Customer value. You are explicitly warned: you can either get a Customer, or no Customer.

Why Maybe works better than null? It's because Maybe is a monad with sound mathemetical foundation, and null is not. List is also a monad, that's what makes it so convenient. With a right approach, monads can be combined in nice ways so that you don't have to check HasValue everywhere. With null, you're stuck with C-style nested ifs for each function result.

Exceptions are also a monad! That's why other answers (correctly) propose to throw an exception. With exceptions, you even get another nice thing typical for functional programming, namely pattern matching (in catch clauses).