Is it better to return a null or empty collection?

Question

Suppose I have a method that returns an array or list or some other collection. If something goes wrong inside or when there is no data to return, which is better - return null or return an array (list, etc.), Which has a length (count) of 0?

Is this really important, or is it just a matter of developer preferences?

Answer 1

Better return an empty collection. Thus, when someone calls a function like this:

foreach(var i in items) { } 

it does not throw a null reference exception for them.

Technically, you can say that empty or null means, but in fact, many people (including me from time to time) forget to get around and not check if the object is null before using it. It plays what other people suggest, which means fewer bugs and less evil users.

Answer 2

Your iteration code will be much simpler if you return empty collections instead of null.

However, it may be important to distinguish between an empty collection and no data collection, so it depends on the semantics of the actual type.

Answer 3

If something “goes wrong,” you should throw an exception. If there is no data to return, return an empty collection. Developers should generally not be surprised at a NullReferenceException when they request a list of elements and there is simply no return.

Answer 4

I could see it anyway. Ultimately, an array or collection has a larger footprint, but is “safer” in the sense that if the result will be used in future foreach / iterations, the result will skip the code block and not end the exception of the null object.

Answer 5

Well, null and empty have two different meanings. An empty collection effectively means “nothing here” and can be valid. How do you know if something went wrong, based on an empty collection?

Although this is safer for the invocation method, it does not do it better than returning a null value. Good practice states that before performing operations on an object, you must check the null value. It’s cheap anyway.

If something went wrong, why aren't you making an exception?

Answer 6

This is actually the preference of the developers.

Return empty list

I usually return an empty list so that the recipient of the method return object does not need to check for null and avoid possible NullReferenceException .

That way, anyone waiting for a list can iterate over the list, even if the list is empty (this will be very fast for each loop).

Return null

If you are in an environment where running out of memory, this is a big problem that you can optimize for returning a null value. However, this means that everyone who uses this method should always check for null and does not solve the problem of possible memory leaks.

Answer 7

If something goes wrong, you should not return anything, but throw an exception.

You need to accept a consistent approach to the project regarding the NULL and {} values ​​and stick to it. Either you are going to use NULL, or not, if you need to know everything to check.

I like to think about NULL - I have not tried or seen if there is something, maybe someone, but who knows.

An empty collection - tried to fill, and as far as the system is concerned, there are no elements, which is a pretty strong statement.

eg. Wallet.Notes Collection.

• NULL - I did not open my wallet, so I do not know if there are any notes in it.
• List = {} - I checked, and I have no notes, because I spent all this on beer.

Answer 8

Here is an article by Josh Bloch explaining the same thing. It is written in the context of Java, but it should apply equally well to C #. Returns arrays of zero length, not zeros

Answer 9

Although I would say that this is mainly a matter of developer preference, returning an empty collection may be the best approach.

Say you have an object that contains a collection item.

 public class Customer { private IList<Order> _orders; public Customer() { _orders = new List<Order>(); } public IList<Order> Orders { get { return _orders; } } } 

As a rule, this participant will prefer as a readonly property that his customer orders are not lost without any apparent reason. So returning null not an option. You are probably working better with an empty collection than with a null reference. So instantiating in a class constructor is a better approach.

And most importantly, for example, when using DataBinding, you may get strange behavior when returning a reference to a null collection, as this will work best with an empty collection.

Another example when iterating through a collection, for example:

 foreach (Order o in c.Orders) { // Do something here... } 

This foreach simply not execute when the collection is empty, without first having to check if it is a null reference. This simplifies the code and minimizes its complexity.

It depends on the scenario in which you are aiming.