Problem

If you used LINQ to Objects you have certainly come across iterations over null values resulting in an ArgumentNullException being thrown at you.

See this example:

int[] b = null;
var query = from i in b select i;

In the case above the error is obvious but if the list comes as an argument of a method or some more complicated way it is hard to spot it. Sure, the obvious solution is an easy one. A simple if statement before will do it:

if (b != null)
    var query = from i in b select i;

What about nested loops? Like this

class Tubo
{
    public List<string> Strings;
}
...
IList<Tubo> tubos = ...;
var query = from t in tubos
            from s in t.Strings
            select s;

Sure, we could add guardian clauses like the if before:

if (tubos != null)
     var query = from t in tubos
        where t.Strings != null
        from s in t.Strings
        select s;

The problem with this approach is that it gets cluttered and it complicates the flow, specially the first if.

Solution

So, here is my proposal and I am sure it has been proposed before (I just couldn’t find it on Google, err, I mean internet).

public static class Extension
{
    public static IList<T> Safe<T>(this IList<T> source)
    {
        if (source == null)
            return new T[0];
        else
            return source;
    }
}

The extension method makes sure that query always gets a non-null list by making an empty one if it is null. The trick with extension method is that they can be invoked on null values which are passed as this argument.

And the last nested LINQ to Objects loop would look like:

var query = from t in tubos.Safe()
             from s in t.Strings.Safe()
             select s;

I am not sure that the extension method name Safe is adequate or not but it sure does help in code readability.

What do you say?

Here is an example where an extension method is useful. Take this [LGP] code for example:

public EntityCollection<CustomersEntity> GetCustomers()
{
    using (DataAccessAdapter da = new DataAccessAdapter("Data Source=[SERVER];Initial Catalog=Northwind;Integrated Security=True"))
    {
        LinqMetaData context = new LinqMetaData(da);
        var q = from c in context.Customers
                select c;
        EntityCollection<CustomersEntity> result = ((ILLBLGenProQuery)q).Execute<EntityCollection<CustomersEntity>>();
        return result;
    }
}

It is a simple LINQ to LLBLGenPro select against (we all love) Northwind database. Pay attention at result assignment. To have data returned as a native [LGP] EntityCollection you have to resort to ILLBLGenProQuery interface. You have to use ILLBLGenProQuery.Execute method on IQueryable q. A cast is obviously required because IQueryable doesn't know anything about ILLBLGenProQuery. While this code works it is not exactly elegant - I am referring to the later cast of course.

So, the idea is to have something like this instead:

EntityCollection<CustomersEntity> result = q.Execute<EntityCollection<CustomersEntity>>();

Possible? Sure, just add this static class with a single extension method and you are good to go:

public static class Tubular
{
    public static TResult Execute<TResult>(this IQueryable q)
        where TResult : IEntityCollection2
    {
        return ((ILLBLGenProQuery)q).Execute<TResult>();
    }
}

Or perhaps, we can further reduce the cluttering by introducing this extension method:

public static class Tubular
{
    public static EntityCollection<TEntity> Execute<TEntity>(this IQueryable q)
        where TEntity : EntityBase2, IEntity2
    {
        return ((ILLBLGenProQuery)q).Execute<EntityCollection<TEntity>>();
    }
}

to achieve this, even less cluttered, line:

EntityCollection<CustomersEntity> result = q.Execute<CustomersEntity>();

Isn't this or former de-cluttered line more readable and more elegant than the original?