Question

Possible Duplicate:
When to use .First and when to use .FirstOrDefault with LINQ?

What is the point of using the First operator in LINQ, when you could use the FirstOrDefault operator instead?

var q = results.First(); // Error if empty

Answer 1

To respond directly to your specific question (why use First if you can always use FirstOrDefault), there are instances where you cannot use FirstOrDefault, because it loses information! The “default value” is likely a valid element type in the source list. You have no way to distinguish between the first element in the enumeration being null/default vs. there being no elements in the list unless you use First or first check if there are Any elements, which requires double-enumeration.

This is especially true for value-typed enumerables, such as int[]. default(int) is 0, which is also most likely a valid value of the array.

In general, the two methods represent different logical flows. First would be used if not having any elements is “exceptional” (an error), which then want to handle out-of-band in your application. In this scenario, you “expect” to have at least one element. FirstOrDefault returns null on an empty set, which means you need to do additional processing with the returned value. This is similar logic to the Parse vs TryParse methods on int/double/etc. In fact, your question in some ways leads itself to the more general question of why to ever use exceptions.

Since First throws an exception, it lends itself to all of the code-reuse opportunities that exceptions provide. For example, you could do:

try
{
    x = arr1.First();
    y = arr2.First();
    z = arr3.First();
}
catch
{
    throw new ArgumentException();
}