Home > Visual Studop > Debugger Friend or Foe

Debugger Friend or Foe

Debugger Friend or Foe?

January 7th | 2009

Debugger: Friend or Foe

The debugger is something that most developers get familiarized with pretty quick. I am not really even going to bother explaining it as it’s such a ubiquitous tool. We all use it for one main reason though: something doesn’t work the way we expect.

I would suggest that it only be used as a last resort. The debugger, while effective and powerful, can lead you down rabbit holes—even if you are familiar with how debuggers work. Rather, start by writing a failing unit test that demonstrates the issue, and proceed from there. After all, if you are in the debugger it’s probably because something isn’t working right. And if something isn’t working right, shouldn’t you have a failing test?

Sometimes though, a failing test is just not enough. In these cases the debugger is a quick way to figure out how something works. It’s easier than sprinkling your code base with calls to Debug.WriteLine. The debugger also allows you to do cool things like modify where it is in the stack execution.

Let’s look at a piece of code. It’s pretty trivial:

class Program
{
    private static int _aNumber = 0;

    static void Main(string[] args)
    {
        int incrementedNumber = GetANumberIncremented();
        System.Console.WriteLine(incrementedNumber);
        System.Diagnostics.Debugger.Break();
    }

    static int GetANumberIncremented()
    {
        return ++_aNumber;
    }
}

Paste this into Visual Studio and hit F5 to make it go. The 3rd line of the Main method should cause you to break into the debugger. This is the same as setting a breakpoint. I only used it so I wouldn’t have to explain where to put a breakpoint. Using the mouse, hover over incrementedNumber. Hopefully you’ll get 1, like I did.

Now let’s try something interesting: Select GetANumberIncremented() including the parenthesis, but not the semicolon. Right-click on the selection and use a familiar tool, Quick Watch. Now we get 2. What gives?

It may be obvious to some, but not to others. The debugger is, in most cases, invasive. Quick Watch is handy, but as we did it on a method we forced the debugger to re-run the method GetANumberIncremented. It’s re-evaluating the stack. With the Quick Watch window open, click “re-evaluate.” Now we get 3. Again, and we get 4, and so on. It’s screamingly obvious in this example, but imagine if it was in a 3rd party assembly and GetANumberIncremented was a public method. We would have no idea what the method was doing. This is a pretty tame case as we’re only incrementing a number. But you can probably imagine instances where this could easily put an application into a state it wasn’t intended for.

Another thing you can get bitten by on the debugger? First chance exceptions. If you aren’t careful the debugger might tell you an exception is being thrown when it is actually being handled gracefully somewhere else. So when the time comes to run the application normally, it will work just fine.

Overall the debugger is an invasive tool that can lead you to some dead ends if you’re not careful.

I wouldn’t go so far as to say the debugger is evil. But I avoid it when I can and opt for unit tests instead. A unit test runs the code just as if it was being used by the application—or at least it should!

Kevin Jones is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Kevin

  1. January 8, 2010 at 1:37 am

    >>> I would suggest that it only be used as a last resort.

    Very true. I have seen most of novice dev always prefer debugging at first place – as if its lollipop. The kind of project I work for has 25+ shared assemblies (and hence that many projects), debugging is the last option I advocate for. Recommended flow to detect error is (at least what I follow):
    – To have (failing) unit test
    – Get some pointers from the error in the log and see if one can reach to root cause
    – No luck? Please yourself with lollipop. 😉

  1. January 8, 2010 at 9:49 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: