LINQ is a great time saving technology that distances the programmer from having to write complex SQL queries when working with databases. It offers a generic means for querying heterogenous IEnumerable data sources. It provides simple object relational mapping.

Object Initializers provide a short hand way of initializing an object in a single statement, rather than having to A) Build numerous constructors for different property combinations or B) Manually set properties one after that other post object creation.

One thing that quickly becomes evident when using object initializers with LINQ queries however (which is a very common thing to do by the way), is the problems associated with debugging LINQ queries that utilise object initializers.

Take for example a very simple query that returns all the people whose first name begins with ‘S’. In this example, we are just returning an anonymous type but you could just as easily return a typed object.

var people = from p in context.Persons
                 where p.FirstName.StartsWith("S")
                 select new
                 {
                     FirstName = (string)p.FirstName,
                     Surname = (string)p.Surname,
                     EmailAddress = (string)p.EmailAddress,
                     Age = (int)p.Age
                 };

One basic rule to remember when working with object initialisers is that they are an all or nothing approach towards object initialisation. This is to protect the object from being only partly initialised. If any one property fails initialisation, the object fails initialisation and cannot be constructed (resulting in an error).

In the case of our LINQ query above, should any one property fail we get an error pointing us to a problem beginning the line our query was declared on; var people = …. Depending on what data source you were working with, what you were trying to do when assigning the property that may have failed and what sort of qualifiers or constraints you had imposed on the LINQ query (such as Single() ) it can be a bit of a trial and error approach to discovering which property or constaint caused the error.

Consider another simple example where again, we are looking for contacts whose first name begins with ‘S’ but this time are quering a Linq to XML data source.

XDocument document = new XDocument("addressbook.xml");
var people = (from c in document.Descendants("Contact")
                where c.Element("FirstName").Value.StartsWith("S")
                select new
                {
                    AddressBookName = (string)c.Ancestors("Addressbook")
                                                .Single().Element("Name"),
                    AddressBookType = (string)c.Ancestors("Addressbook")
                                               .Single().Element("Type"),
                    FirstName = (string)c.Element("FirstName"),
                    Surname = (string)c.Element("Surname"),
                    EmailAddress = (string)c.Element("EmailAddress"),
                    Age = (int)c.Element("Age
                }).Single();

This is a completely fictious example to demonstrate a point. But looking at this example there are easily several problems that could occur. The query could return more than one result where we have declared it to be Single. This could be the entire query where we are only expecting one contact, or it could be the AddressBookName or AddressBookType. Any of the string castings could fail giving us no indication as to which property failed.

Using object initializers with LINQ provides quick, flexible and powerful object querying and manipulation. Whilst quick to write, it still pays to be aware of the potential maintenance issues further down the track when you encounter data your query doesn’t handle so well. Even trivial examples like the aforementioned can take multiple debug attempts in order to ascertain the real problem.

Do you have any good techniques for debugging linq queries and object initializers?