IEnumerable null coalescing Extension

2019-01-28 02:01发布

问题:

I frequently face the problem to check whether an IEnumerable<T> is null before iterating over it through foreach or LINQ queries, then I often come into codes like this:

var myProjection = (myList ?? Enumerable.Empty<T>()).Select(x => x.Foo)...

Hence, I thought to add this extension-method to an Extensions class:

public static class MyExtensions 
{
    public static IEnumerable<T> AsEmptyIfNull<T>(this IEnumerable<T> source)
    {
        return source ?? Enumerable.Empty<T>();
    }
}

A little issue comes immediately in my mind looking at this code, i.e., given the "instance-methods aspect" of extension-methods, it should be implemented as a mere static method, otherwise something like this would be perfectly legal:

IEnumerable<int> list = null;
list.AsEmptyIfNull();

Do you see any other drawback in using it ?
Can such extension leading to some kind of bad-trend in the developer(s), if massively used?


Bonus question:

Can you suggest a better name to it ? :)
(English is not my first language, then I'm not so good in naming...)

Thanks in advance.

回答1:

Methods that return an IEnumerable<T> should return an empty one, instead of null. So you wouldn't need this.

See this question : Is it better to return null or empty collection?

Otherwise, your code seems ok.



回答2:

It's generally a bad idea to return a null instead of an empty sequence if you can control it. This is self-explanatory if you consider that when someone is asked to produce a collection, returning null is not like saying "the collection is empty" but "there is no such collection at all".

If you own the methods returning the enumerables, then returning an empty IEnumerable (which can even be a special purpose readonly static object if it might be returned a lot) is the way to go, period.

If you are forced to use a bad-mannered library that has the habit of returning null in such cases, then this an extension method might be a solution, but again I wouldn't prefer it. It's probably better to wrap the bad-mannered methods in your own versions that do the coalescing where people won't see it. This way you get both the convenience of always having an enumerable instead of null and the correctness of not supporting the "return null" paradigm.