You are hereConditional Breakpoints in Visual Studio 2005

Conditional Breakpoints in Visual Studio 2005

By hagrin - Posted on 04 August 2008

Sometimes when you are self-taught, you may know how to do something, but you do it the hard way. Therefore, sometimes even the smallest little feature you didn't know about can really make your day and improve your coding efficiency. Today, I stumbled over the addition of conditional breakpoints in Visual Studio 2005. Now, I'm sure any serious coder probably already stumbled over this feature, but I had not until today. A conditional breakpoint is exactly what it sounds like - it is a breakpoint that will be triggered during the debugging process only when a condition you specify is met.

Conditional Breakpoints in Visual Studio 2005

Using Visual Studio 2005, you can set a conditional breakpoint by placing a breakpoint on a desired line much like you have in the past (click the gray area to the left of the desired line). A red dot will appear representing the breakpoint. When a user right clicks on the breakpoint, you will be presented with a list of options that include:

  • Delete Breakpoint
  • Disable Breakpoint
  • Location
  • Condition
  • Hit Count
  • Filter
  • When Hit

Anyone who used Visual Studio 2003 as their primary development environment would be surprised to see all these new options in the 2005 version. If you choose the "Condition" option, you will be presented with a dialog box that asks you to input a condition and to choose whether the condition "Is True" or "Has Changed".

Conditional breakpoints are extremely important for debugging problems that exist in WHILE loops, FOR ... NEXT loops, etc. especially when dealing with extremely large loops. Say you have a single record bombing out in a huge loop and you are being emailed the CATCH exception. Instead of setting a breakpoint and continually hitting F5 to eventually get to the record that your application is bombing out on, you can now just set a conditional breakpoint, run your application and have the debugger stop the process right as you get to the problem record.

I'm excited to have "discovered" (yeah, I know, I'm late to the dance on this one) this feature as it should drastically improve my debugging and shorten troubleshooting time. Hopefully, if you weren't already aware of this feature, you are now and will help you in your .Net development.