What to return from a failed method and when to throw?

Question

I´ve lately been thinking about the things i´m returning from methods and I noticed that there are 4 different things i return when the method fails.

What bothers me about it, is that my code is not very consitent in this regard, so i wanted to ask about your "best practices".

So lets imagine a method that takes Foo and returns a list of Bar:

public IList<Bar> Method(Foo something);

Or to keep it more general:

public IBar Method(IFoo something);

The question is what do you return on what kind of failure. the options would be:

1. empty return type like: new List; or: new EmptyBar();
2. null
3. throw an exception
4. a special list value indicating failure like: new List{new FailureBar()}

I really hate option 4 so I´m mostly interessted to hear when you use the other 3 options and why

Answer 1

I'd choose between an empty list and an exception depending on the nature of the failure.

E.g.

If your database failed to connect - exception.

If your query didn't return results - empty list.

Answer 2

If your business logic can vary depending on what Method returns and thus it is ok to your Method to return empty list then go with 1).

Throw an exception if your business logic has no intend to have an empty list. If it is because of wrong passed 'Foo something' go with Assert or logic exception. If it is because of external data problem like database connection or filesystem error then ggo with runtime exception.

Never go with 4) it will be very hard to understand this behavior later.

Answer 3

Case 1:

If Method, encounters a problem, which does is not expected it should throw an exception. The calling code should take care of Exception

Case 2:

All other cases Method should return null/empty/list with values. The calling function should take care of null and empty.

Answer 4

It depends on what you mean by 'failure'.

If it is a failure in the sense that something unexpected happened, then I'd throw an exception. Maybe an argument exception for when the parameter was incorrect, an IOException when you couldn't read from file, etcetera.

If the 'failure' is that no items could be found for the given parameter value, then I'd return an empty List. In case you'd return an object that is not a collection, I'd return null.

I never return special result codes, like -1 on error. I really don't like it. People tend to forget about codes, they change over time, you end up with badly maintanable if statements that check for these result codes, etcetera.

Answer 5

Not sure if these can be universally applied, but I'm rather comfortable with following rules:

1. If method's name is DoFoo, it should throw if it's unable to do Foo for some reason: network resource is unavailable, doing Foo is not supported by this particular implementation of the interface, object is in inconsistent state etc.
2. If the method's name is GetBar, there's one more option: returning null. But it's better to reflect this by naming it like TryGetBar, GetBarOrNull etc. Of course, null return value should indicate something special and to be response to every exceptional condition.

Answer 6

I would throw an exception only when something interferes with what I'm trying to do, such as bad input parameters, database errors etc.

I usually go with returning a null in most other cases, because checking for nulls comes naturally, but I'd return an empty list if the data it's supposed to hold is simply empty.

Answer 7

If there's an expected exceptional case, I'd throw an exception.

If I was looking for Bar and didn't find it, I'd return null.

If I was looking for List<Bar> and didn't find any, I'd return an empty List<Bar>.

If finding null was going to be very common, and it made sense to use it, I'd implement the Null Object pattern, and return EmptyBar.

So...I think it's fair to say that I agree with your current approaches now. I'd just make sure that I was consistent in any project and not mix & match different approaches with different cases.

Answer 8

If there are no elements found, return an empty list. This is a particular case of the Null Object pattern. It helps to treat all cases consistently, meaning clients won't have to check if the value is null. Or worse, if they don't check, a Null Pointer Exception is thrown and happy debugging to find out what the cause is. Only return null if you have a very good reason for it.

Update: Martin Fowler describes a better alternative to returning null: http://martinfowler.com/eaaCatalog/specialCase.html

But throw an exception if your method didn't behave as it was supposed to, database exceptions, stream exceptions, etc.

Answer 9

There arw two questions to answer here:

• Is a failure of the function conceptually different from regular execution with an empty result? Could a caller realistically need to know which of these cases happened? If so, returning an empty list is not an option. I guess in theory you could return a "special" empty list, but that's obfuscation.
• If the function fails, who will typically need to react? If it's not the immediately calling code but something higher up, an Exception is the cleanest solution.

Answer 10

I'd reduce it to exception or empty return list to keep it as simple as possible

1. empty return type like: new List; or: new EmptyBar();

You should return this when the operation to fill the list has completed correctly with no obvious error, but no results are returned - as this is what it implies IMO. This also means that code dependent on the return which (for example) loops through the list will need no special handling.

1. throw an exception

IMO Exceptions should be thrown when something has gone wrong in the function - e.g. cannot open file, connection cannot be made etc. Calculation returned garbage - This is distinct from "no results returned"