Linq is great for its compact expressions, and for its -- usually efficient -- lazy-evaluation. These two virtues seem to be spit upon by the Aggregate function.

Say you want to aggregate a list of ints.

var s = new int[] {1, 2, 3}; int sum = ints.Aggregate((a,b) => a + b); 

This works great if your list has elements in it, or they aren't filtered out in a where clause. Say you had a function that took a list of ints and someone passed that list of 1,2,3 to your function:

int SumOverTen(IEnumerable<int> ints) { int agg = ints.Where(i => i > 10).Aggregate((a,b)=> a+b); return agg; }

Everything now goes pear-shaped and you get an InvalidOperationException "Sequence contains no elements".

So what do you do to fix this? You could rewrite your function to check for an empty result first:

int SumOverTen(IEnumerable<int> ints) { int agg = 0; var bigints = ints.Where(i => i > 10); if(bigints.Count() > 0) agg = bigints.Aggregate((a,b)=> a+b);

 return agg; 

}

This makes a nice Linq expression into a nasty branching mess. The list will now be enumerated twice, once for Count and once for Aggregate.

Well, it turns out that there is a better way, using Linq:

int SumOverTen(IEnumerable<int> ints) { int agg = ints.Where(i => i > 10) .DefaultIfEmpty() .Aggregate((a,b)=> a+b);

 return agg; 

}

This results in the same value as the previous function but is much more legible and throws no exceptions on an empty list. However, I don't know how DefaultIfEmpty checks for an empty list so it may not be more efficient than the previous code.

What I want to know is, why does Aggregate throw instead of returning the same result as using DefaultIfEmpty?