Conditional Breakpoints, oh yeah
I’ve known they existed for a while, but this week is the first time I’ve really used the new Conditional Breakpoints in Visual Studio 2005. Conditional breakpoints are a straightforward enough concept: you can set a condition on a breakpoint using the same C#-like (or I guess VB-like) syntax you use in the VS Watch panel. If the condition is true, the breakpoint is hit; otherwise it justs skips past instead.
Most of the time this isn’t hugely useful. If not every breakpoint hit is interesting, you can just F5 through those that aren’t. Right now though I’m working on a project that loops through a set of complex data, and maybe 1% of the time I want to break into the debugger. Suddenly I absolutely love conditional breakpoints.
There are a couple of (minor) drawbacks, for example the condition isn’t evaluated until the breakpoint is executed, so if you’ve used some dodgy syntax you won’t find out immediately. There’s no Intellisense either, but again, it’s not a major problem — you’re not going to be typing long sections of code here, it’s just a simple condition.
If you haven’t tried these out, give them a whirl — just right click the little red breakpoint, and choose Condition… There are a couple of other fun things in there too: filters to only break when you’re running a particular thread or process, hit counts so you can stop after a number of hits, and a nice When Hit option so you can trace when the breakpoint occurs without actually stopping.
Jim Gries has a great blog with debugger tips, though sadly it hasn’t been updated since December 2005. There’s still some great stuff there however: check it out at http://blogs.msdn.com/jimgries/default.aspx.