Friday, April 25, 2008

Conditional Breakpoints

Ok. I finally got my hands on VS08 and I hope, by the end of this week I can have some useful information to pass along. Meanwhile, here is a subject that's often unknown by most programmers, since VS is a huge tool and has a lot of features: conditional break points. While not cannon to the development process, this feature can help you to create a very complex and robust debugging ground for your application.

The idea is simple, after you create break points in the desired code lines, you can say when this breakpoint is supposed to actually pause the debug instead of doing it every time you reach that line. The process of creating a condition to your breakpoint (from now on, we'll use BP to name it) is easy. You simply create your BP, then right click it and select condition, a condition sentence window pops up and you can write the sentence to dictate the actual breaking. There are two sentence types for you to choose from: one that will return a Boolean value, and when the sentence is true, the BP will pause the process, or one that keeps an eye on when the sentence return value is changed, in which case the BP will too pause the execution. Simple enough right?

So when is this useful? Well, when you are testing a loop which has been breaking due to one specific element. Recently I've been writing code to parse a text file and turn it into a bunch of XMLs. So far it seems trivial, but the thing is that each text file has about 50Mb and generate up to 750 XML files of up to 15Mb each. So my loop was running for a while and each iteration involved a big number of methods intricate in the class hierarchies. I had the information that it was breaking in the 19th iteration of the 128th element. So instead of creating cluttered code to break the execution on that iteration, I just used a conditional BP with a sentence that would return true when those and a few other conditions were true and surely enough, problem solved.

This simple feature helped me save a lot of time debugging and prevented me from leaving trash code that I could forget to remove once the defect was corrected. BPs have a few other interesting and powerful features such as hit counts (which enables you only break when the hit count is either equal to, multiple of or greater than or equal to a user defined number), filters and when hit (used to define a course of action when the BP is hit).

So, I hope this will help you debug your applications faster, more robustly and more precisely.


No comments: