Debugging C# 3.0 Part II

DotNetKicks.com — Fri, 30 Nov 2007 03:15:25 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Debugging C# 3.0 Part II

Eamon Nerbonne — Sat, 01 Dec 2007 17:11:54 GMT

It also unfortunately fails to fix the rather annoying limitation that expressions in immediate code and watches cannot contain lambda expressions; not even lambda expressions which don't reference any local variables but are entirely self-contained (and should certainly be generatable by the IDE).

It seems that the IDE can't compile lambda's on the fly. So, by extension, what's equally not possible is Edit and Continue in any scope which also contains a lambda expression, or an expression in the immediate window which contains a lambda.

That's a big limitation; Unlike procedural code which frequently must be excessively explicit about the minutiae of a data structure and thus in which case debugging is usually straightforward (if tedious), code relying on LINQ heavily can so easily filter and remap a list, that the exact nature of a list after a particular transformation is often never in a local variable and never easily inspectable.

Even obvious flaws can be hard to debug, requiring that you split out a long but readable query into a multitude of separate queries in a far less readable (and efficient) fashion, and if it's code that's badly understood and requires frequent debugging, you'd be tempted to leave the code in it's inefficient, unreadable form merely to make the necessary debugging sessions simpler.

As is, I'm impressed by the debugger, but it's just not enough to really help debugging issues in LINQ code. If a list is only ever accessed in some remapped form or other in code, a debugger must be able to show me that remapped form to be useful; even if it's not stored in a variable name in scope, and ideally, I'd be able to slightly modify the query debug-time to improve its utility.

re: Debugging C# 3.0 Part II

Sree_c — Thu, 06 Dec 2007 03:18:37 GMT

I Agree with you Eamon, many of the functional constructs in the language create many intermediatary types that are not easy to debug or try out. More so if the user wishes to create Ad-Hoc queries or lambda expressions to disgnose a problem in his code, he can't do that with out restarting the debug session.

Lambda expressions are a good eg of this, i would certainly like to fix this hole in the debugger and allow for lambda expression to be created with a copy symantics ( where the lambda expressions is only valid for the stack frame its created on) .

There are a lot of ideas we have and some of them are being discussed in the team.

I would be very interested in knowing from you specific instances of in your code where you felt that the debugging experience was lacking...

thanks Sree