When to raise an exception or return null?

Question

I have several data access level features

public Order RetrieveById(int id) public List<Order> RetrieveByStatus(OrderStatus status) 

Now I'm a little confused about creating exceptions.

In the case of the RetrieveById function, an identifier that is less than 1 is an invalid identifier, so I feel like throwing an exception. And I want to return null for an Id that is not in the database. Then it seems to me that I'm complicating.

In the case of RetrieveByStatus, I want to return an empty list if the database does not have data for this status.

However, I saw some people throw an exception when RetrieveById cannot return anything, but then should RetrieveByStatus not raise an exception if there is no record or should it be?

Can someone clarify these concepts for me?

Answer 1

In the first case, I could throw an exception and handle myself, instead of returning null. What if your first method is used in such a way that the returned object is stored in the Order.There link has a very high probability of a NullReferenceException when someone then tries to call a method or property for this object.

For the second method, I would choose an empty list, as some have suggested.

Answer 2

I would prefer to return null in the first case and empty list in the second case.

But if you want to raise an exception, you can throw an exception for public Order RetrieveById(int id) because it means id invalid, since calling the first method means you know id , and it should be there.

In the second case, OrderStatus may be valid and there is no record found against it, so an empty list is a good idea.

Answer 3

• First read MSDN: Creating and Throwing Exceptions (C # Programming Guide) . It lists both situations when you expect to throw an exception and when to avoid it.
• Also keep in mind what are the real overheads of try / catch in C #?

In either case, you will have to handle either a zero return or an exception thrown

---

As for me, I would prefer that an exception be not explicitly thrown out in both methods. I would say there is nothing wrong if your method returns null, if it could not find the object by id. While the RetrieveByStatus method could return an empty collection, not null.

Alternatively, you can follow the pattern used in LINQ, where you have, say, Enumerable.First and Enumerable.FirstOrDefault (either throwing an exception or returning null), so you can use the appropriate one in a specific situation when the id is 100% valid or when on the contrary, it may be absent. Although methods that return a sequence of elements do not throw an exception if the sequence to return seems empty; consider Enumerate. Where .

Answer 4

I like to avoid returning zero when possible, because NullRefExceptions much more mysterious than a specific exception, say OrderNotFoundException . Also, the code gets pretty dumb when you have to constantly expect entities to be zero. In any case, this should be an exception case - where did you get this identifier if it does not exist in db?

In cases where you suspect that this is most likely to lead to an error, you can add a method like DoesObjectExist or TryGet (or even an extension method).