Know Your Debugger Part 3: Breakpoint Types

DZone 's Guide to

Know Your Debugger Part 3: Breakpoint Types

· ·
Free Resource

Breakpoints are a very important part to the whole debugging story.  By using them properly you can break your application's execution at a certain point and then inspect (or even modify) your application.  What you may not know, however, is that Visual Studio has many types of breakpoints, not just the standard red dot.  

There are 5 breakpoint options available to you.  If you set a breakpoint and then right click on it, you will get the following dialog:

The breakpoint by default is a Location breakpoint and is displayed with the standard red circle in the gutter you are used to.

You can change the line and even the character you want to break on.  That means if you have a statement with multiple parts you can break on just that part and not the whole statement. A for loop is an example of this.

The second breakpoint option is a Condition and when used will put a small plus ("+") sign in your breakpoint letting you know there are additional options configured.  This one is very useful as it will only break when a condition is met:

The condition you put in here can literally be anything you can do it code but it must either be a boolean and look for true of you can select "Has changed" and the expression will be evaluated each time the breakpoint is hit and will break when the value changes.  When I mean you can put any code in here, you really can.  If you can put it in an if statement, it can go here, including method calls.

The third breakpoint option is Hit Count.  It has the same plus sign that the condition does.  

It very simply gives you a hit count if you want to know how many times the breakpoint has been hit.  I don't use this one a great deal, but it can certainly give you some useful information.  It is very helpful when used in conjunction with the When Hit option.

The fourth breakpoint option is Filter and your icon will have the plus sign as well:

The filter will allow you to filter when the breakpoint gets hit by machine, process or thread.  This can be extremely useful when trying to debug a multithreaded application. If you have ever tried, you will know that if you have a breakpoint on a line of code and 10 threads running that code, it will break on every thread making it virtually impossible to follow a line of execution.  The filter will help greatly with that.

The last breakpoint option is When Hit and the icon will change to a diamond.

Here you have 3 options on this dialog.  You an print a message to the debug trace or you can run a macro.  What I really want to bring to your attention is the "Continue execution" checkbox.  This will allow your breakpoint to get hit but not actually break your application giving you execution monitoring capability very easily.

As you can see there are several options to when working with breakpoints for debugging.  Most of us will use the standard location breakpoint most, but the other options are very handy when you need them.  If you are doing multithreaded programming, you really have to take advantage of the additional options available to you.  


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}