What result i should return? [duplicate]

9

This question already has an answer here:

I write simple library wich returns List of names.

But,what i should returns if i can not find anything?

return new List<String>();

or 

return null;

example:

var resultColl=FindNames(...);

This code can be used from another components and i do not want to corrupted it. If i return null- i think it is right way to check it. But, may be i should return empty list?

Thank you.

Admiral Land

출처 c# .net
  • empty List would be fine i think instad of null - Ehsan Sajjad
  • Note, that you shouldn't return List<T> at all. Return empty IList<T> or, if it is possible, empty IEnumerable<T> instead. - Dennis

8 답변

15

You should always return empty list. See the Guidelines for Collections.

DO NOT return null values from collection properties or from methods returning collections. Return an empty collection or an empty array instead.

  • absolutely, avoid using null as much as possible. it's just library should offered some default empty implementations. - zinking
5

Returning the empty list is more convenient for users of your function:

foreach (string name in FindNames(...))
{
   Display(name);
}

Returning null forces your callers to write extra code:

  • a test for null, and

  • an extra local variable (to avoid having to call your function twice)

    List<string> names = FindNames(...);

if (names != null)
{
   foreach (string name in names)
   {
      Display(name);
   }
}

So returning an empty list is better.

5

I'd return Enumerable.Empty<string>(), or if your method is supposed to return a List, do return new List<string>(). If you have a lot of situations where you need to return an empty List, you could create a static list which is returned each time, this would stop new empty lists from having to be created each time, as pointed out by @YuvalItzchakov.

An empty collection is better than null since it would, in my opinion lead to cleaner code.

  • You probably ment Enumerable.Empty<string>().ToList(); - Yuval Itzchakov
  • @YuvalItzchakov Why? If you go that route, just do new List<string>(); - Rob♦
  • @Rob Unless the OP is receiving an IEnumerable<string>, this wont compile. As he used List<string>, i assumed that's what he's using. - Yuval Itzchakov
  • @YuvalItzchakov: I do not know what is the OP expecting, but if List<string> is expected then it would need to be converted, but then again it would make the use of Enumerable.Empty redundant. - npinti
  • @npinti In that case, I think creating a static List<string> would be better, performance wise. - Yuval Itzchakov
3

It's likely that the calling code will want to iterate the list, or do something with a List. By passing back an empty List the calling code should work fine. If you return null then the calling code will have to ensure they have a list first.

It's probably just a matter of preference, but returning an empty list gets my vote ... you're returning the thing the contract said it would return.

2

Returning empty collection is better from the design perspective because client code doesn't need to perform null checking. See Null Object pattern.

1

That depends on the semantic of your code.

If no results is an acceptable result, then you should return an empty collection.

If no results is an error condition, then return null.

  • If no results is an error condition, consider throwing an exception! - Matthew Watson
  • @MatthewWatson you're right, exception would be better than returning null - Domysee
1

I would suggest that you be consistent in what you do when you have nothing to return. This way you always know for anything that you are calling to expect the same type of response for nothing. Such as knowing that you will always return an empty set or an empty string or 0 etc.

What do you do in regards to the other library items you have?

0

A more detailed answer would be a Tuple<bool, List<string>>. This is a clear solution which can be modified to include other details about your search:

var thereAreResults = foundList.Count > 0;
return new Tuple<bool, List<String>>(thereAreResults, foundList);

  • No reason from the downvoter? - tomab
  • That's a horrible horrible design. It also doesn't compile. - Rob♦
  • I didn't down vote, but this seems pointless since the caller can just call Count on the returned list or more likely iterate it in a foreach. Also you could just return Tuple.Create(thereAreReullts, foundList); instead. - juharr
  • The emphasize was a way to include more information than just an empty List(). But nevermind. - tomab

Linked

Latest