When to use .First and when to use .FirstOrDefault with LINQ?

Question

I've searched around and haven't really found a clear answer as to when you'd want to use .First and when you'd want to use .FirstOrDefault with LINQ.

• When would you want to use .First? Only when you'd want to catch the exception if no results where returned?

  var result = List.Where(x => x == "foo").First();

• And when would you want to use .FirstOrDefault? When you'd always want the default type if no result?

  var result = List.Where(x => x == "foo").FirstOrDefault();

• And for that matter, what about Take?

  var result = List.Where(x => x == "foo").Take(1);

Answer 1

.First() will throw an exception if there's no row to be returned, while .FirstOfDefault() will return a NULL value instead.

So if you're preprared and willing to handle a possible exception, .First() is fine. If you prefer to check the return value for != null anyway, then .FirstOrDefault() is your better choice.

But I guess it's a bit of a personal preference, too. Use whichever makes more sense to you and fits your coding style better.

Marc

Answer 2

I would use First when I know or expect the sequence to have at least one element. In other words, when it is an exceptional occurence when the sequence is empty.

Use FirstOrDefault, when you know that you will need to check whether there was an element or not. In other words, when it is legal for the sequence to be empty. You should not rely on exception handling for the check. (It is bad practice, and might hurt performance).

Finally, the difference between First and Take, is that First returns the element, while Take returns a sequence of elements, that contains exactly one element. (If you pass 1 as the parameter, of course).

Answer 3

.First will throw an exception when there are no results. .FirstOrDefault won't, it will simply return either null (reference types) or the default value of the value type. (e.g like '0' for an int.) The question here is not when you want the default type, but more: Are you willing to handle an exception or handle a default value? Since exceptions should be exceptional, FirstOrDefault is preferred when you're not sure if you're going to get results out of your query. When logically the data should be there, exception handling can be considered.

Skip() and Take() are normally used when setting up paging in results. (Like showing the first 10 results, and the next 10 on the next page, etc.)

Hope this helps.

Answer 4

First of all, Take is a completely different method. It returns an IEnumerable<T> and not a single T, so that's out.

Between First and FirstOrDefault, you should use First when you're sure that an element exists and if it doesn't, then there's an error.

By the way, if your sequence contains default(T) elements (e.g. null) and you need to distinguish between being empty and the first element being null, you can't use FirstOrDefault.

Answer 5

I found a website that apperars to explain the need for FirstOrDefault
http://thepursuitofalife.com/the-linq-firstordefault-method-and-null-resultsets/
If there are no results to a query, and you want to to call First() or Single() to get a single row... You will get an “Sequence contains no elements” exception.

Disclaimer: I have never used LINQ, so my apologies if this is way off the mark.

Answer 6

someList.First(); // exception if collection is empty.
someList.FirstOrDefault(); // first item or default(Type)

Which one to use? It should be decided by the business logic, and not the fear of exception/programm failure.

For instance, If business logic says that we can not have zero transactions on any working day (Just assume). Then you should not try to handle this scenario with some smart programming. I will always use First() over such collection, and let the program fail if something else screwed up the business logic.

Code:

var transactionsOnWorkingDay = GetTransactionOnLatestWorkingDay();
var justNeedOneToProcess = transactionsOnWorkingDay.First(): //Not FirstOrDefault()

I would like to see others comments over this.