First() fails to throw exception

Posts   
 
    
GregWoods
User
Posts: 2
Joined: 24-Jan-2011
# Posted on: 24-Jan-2011 12:30:10   

LLBLGenPro 2.6

I have the following simple query

var site = (from s in Linq.Site
                where s.UnitCode == unitCode
                select s).First();

where 'Linq' is Generated.Linq.LinqMetaData

My code relies on the standard Linq behaviour which should throw an error if no entities are found. Instead this code is returning null, which is the behavious of FirstOrDefault().

What is the reason for this? (my ignorance is a very likely reason!)

Thanks

Greg

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 24-Jan-2011 12:45:01   

Exceptions aren't a way to do control flow. The First() or FirstOrDefault() methods both simply will perform a limit of 1 on the query. There's no information if there should be an exception AFTER the query has been executed.

So First() won't throw an exception, if you want control flow whether a row was returned, use an if statement and a null check and use FirstOrDefault().

Frans Bouma | Lead developer LLBLGen Pro
GregWoods
User
Posts: 2
Joined: 24-Jan-2011
# Posted on: 24-Jan-2011 13:10:09   

I thought I'd try using exceptions in this case. They are actually warnings to be logged rather than fatal errors. I am importing a user's xls file into the database, with several data lookups on the way. During the course of an import there can be many causes of problems which need logging and shown to the user at the end. For most of these, execution must continue past the error. Using exceptions is not something I've done before, and I may soon come to realise the error of my ways. It kind of seemed appropriate in this case, but it may trip me up yet.

p.s. Your post before you edited it contained the tip to use Single() instead of First(). This was very useful. In my limited Linq experience I hadn't come across it, I had always used First() or FirstOrDefault(), but Single() is a much better choice. Thanks

Greg

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39908
Joined: 17-Aug-2003
# Posted on: 25-Jan-2011 16:37:21   

GregWoods wrote:

I thought I'd try using exceptions in this case. They are actually warnings to be logged rather than fatal errors. I am importing a user's xls file into the database, with several data lookups on the way. During the course of an import there can be many causes of problems which need logging and shown to the user at the end. For most of these, execution must continue past the error. Using exceptions is not something I've done before, and I may soon come to realise the error of my ways. It kind of seemed appropriate in this case, but it may trip me up yet.

p.s. Your post before you edited it contained the tip to use Single() instead of First(). This was very useful. In my limited Linq experience I hadn't come across it, I had always used First() or FirstOrDefault(), but Single() is a much better choice. Thanks

Greg

I removed it as SingleOrDefault() throws an exception if there are more than 1 rows or 0 rows, which is different from FirstOrDefault() which allows multiple rows and simply wants 1 row. So I gave wrong advice. Still great it set you on the right track though wink

Frans Bouma | Lead developer LLBLGen Pro