Let's say you are given the following...

List<Thing> theThings = fubar.Things.All();

If there were nothing to return, what would you expect fubar.Things.All() to return?

Edit: Thanks for the opinions. I'll wait a bit and accept the entry with the most ups.

I agree with the responses so far, particularly those suggesting an empty collection. A vendor provided an API with several calls similar to the example above. A vendor who did $4.6 million in revenue via their API(s) last year, BTW. They do something I fundamentally disagree with -- they throw an exception.

  • Seems to be a pretty solid consensus [here][1]: Empty collection. Always. [1]: stackoverflow.com/questions/1969993/… Aug 16, 2012 at 18:09
  • What is the datatype for Things? If it makes sense to have the Things field return null, then it makes sense for you to receive an exception because you did not check for null before your call to All(). However, I agree with the people who think fubar.Things should return an empty collection instead of null.
    – Colin D
    Aug 16, 2012 at 18:53
  • I see what you are getting at, Colin. In this case, you can assume Things exist and All() is static. The exception is specific to the collection being empty, not some other reason.
    – abscode
    Aug 16, 2012 at 21:54
  • OMG they throw an exception ... ! o_O Aug 17, 2012 at 1:02
  • Now, the more interesting question would be what reason on earth anyone could have to Throw in such a generic case, or what makes the case so special to warrant Throwing??!
    – Martin Ba
    Aug 17, 2012 at 7:27

6 Answers 6


Of the two possibilities (i.e. returning a null or returning an empty collection) I would pick returning an empty collection, because it lets the caller to skip a check of the returned value. Instead of writing this

List<Thing> theThings = fubar.Things.All();
if (theThings != null) {
    for (Thing t : theThings) {

they would be able to write this:

List<Thing> theThings = fubar.Things.All();
for (Thing t : theThings) {

This second code fragment is shorter and easier to read, because the nesting level is lower by one.

  • 2
    I think I'd also find it easier to understand conceptually as 'the set is empty' (no items). Null is 'there is no set', which is quite different. (This should also cover things that are logical impossibilities - the set of all items that are odd that are also even should be empty, not null). I'm honestly not sure what (logically) would constitute a null set... (even if you're buck naked on an island, your possessions are an empty set, not a null one) Aug 16, 2012 at 17:46
  • @X-Zero But if you're buck naked, "possessions in backpack" could return a null set, since you don't even have a backpack on you. It could be a BackpackNotFoundException, but only if it's truly unexpected. It should be a normal state in, say, an island survival game.
    – Izkata
    Aug 16, 2012 at 19:38
  • The extra null check is what helps me sleep at night.
    – Joel B
    Aug 17, 2012 at 0:37

I would expect an empty list. theThings would still be an object, but theThings.Count or theThings.size() would return 0.


Design issues like that are addressed by Null Object pattern

...Instead of using a null reference to convey absence of an object (for instance, a non-existent customer), one uses an object which implements the expected interface, but whose method body is empty. The advantage of this approach over a working default implementation is that a Null Object is very predictable and has no side effects: it does nothing.

For example, a function may retrieve a list of files in a directory and perform some action on each. In the case of an empty directory, one response may be to throw an exception or return a null reference rather than a list. Thus, the code which expects a list must verify that it in fact has one before continuing, which can complicate the design...

Suggestion particularly applicable in your case (returning List when there are no Things) is:

...By returning a null object (i.e. an empty list) instead, there is no need to verify that the return value is in fact a list. The calling function may simply iterate the list as normal, effectively doing nothing. It is, however, still possible to check whether the return value is a null object (e.g. an empty list) and react differently if desired.


You should, IMHO, return a EMPTY value. I don't know about C#, but in Java we have this:

  List list = Collections.EMPTY_LIST;
  Set set = Collections.EMPTY_SET;
  Map map = Collections.EMPTY_MAP;

  // For the type-safe 
  List<String> s = Collections.emptyList();
  Set<Long> l = Collections.emptySet();
  Map<Date> d = Collections.emptyMap();



I would return an empty collection over returning a null value because that way you can avoid writing a null verification in the calling code.


The two solutions they mean different things.

If there are just zero of the thing you are returning, you ALWAYS return an empty collection! Take the case of a directory listing. If there are no files in the directory you return an empty collection of files.

On the other hand, if the directory doesn't exist, that's not really appropriate. "I can't return anything" means something compeltely different. In that case you should either return null or throw an exception depending on the situation, don't just return an empty collection like nothing was wrong.

  • Very reasonable explanation. The result returned should not cover for invalid state, we have exceptions for this. Nov 26, 2014 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.