Unsweetening the LINQ Syntactic Sugar

Of all the features built into the .Net framework, LINQ is probably my single favorite. However, sometimes the "syntactic sugar" that LINQ produces can be quite bitter when you get a runtime error and you start trying to decipher some cryptic stack trace where the line causing a problem looks something like "MyNamespace.MyClass._Closure$__111._Lambda$__97". Recently a colleage of mine shared a neat idea/tip on how to make sense out of these errors.

Credit for this idea goes to Jeff Walker, a fellow consultant of mine at Quick Solutions. I would like to thank Jeff for this idea and also thank him for not having a blog so that I can steal and publish his ideas(with permission).

If you have a lot of LINQ code, figuring out which statement is actually causing the problem can be a guess and check experiment when you get an error like this. Jeff's idea which I thought was brilliant, open the compiled code in reflector. Once you do this you can easily find the symbol referenced in the stack trace and decompile the code to find out which statement is actually causing the issue.