views:

179

answers:

4

I want to be able to break on Exceptions when debugging... like in Visual Studio 2008's Menu Debug/Exception Dialog, except my program has many valid exceptions before I get to the bit I wish to debug.

So instead of manually enabling and disabling it using the dialog every time is it possible to do it automatically with a #pragma or some other method so it only happens in a specific piece of code?

+1  A: 

Wrap your try catch blocks in #if DEBUG

    public void Foo()
    {
        #if DEBUG
        try
        #endif
        {
            //Code goes here
        }
        #if DEBUG
        catch (Exception e)
        {
            //Execption code here
        }
        #endif
    }

I like to keep the curly braces outside of the #if that way it keeps the code in the same scope if inside or outside of debug.

If you still want the execption handeling but want more detail you can do this

        try
        {
            //code
        }
        catch (FileNotFoundException e)
        {
            //Normal Code here
            #if DEBUG
            //More Detail here
            #endif
        }
        #if DEBUG
        catch (Exception e)
        {
            //handel other exceptions here
        }
        #endif
Scott Chamberlain
using something like this is looks a little cleaner:[Conditional("Debug")]private void MyMethod() { ...}
Nate Zaugg
My problem is not with the try catch but breaking into debug on the Throw....
Tony Lambert
+2  A: 

What about conditional breakpoints? If I understand correctly, you can have a breakpoint fire only when the value of a certain variable or expression is true.

Jeremy
+1  A: 

This is a bit of too late for you, but this is the biggest reason I often try to teach people to use exceptions conservatively. Only use exceptions when something catastrophic has happened and your ability to reasonably continue is gone.

When debugging a program I often flip on First Chance Exceptions (Debug -> Exceptions) to debug an application. If there are a lot of exceptions happening it's very difficult to find where something has gone "wrong".

Also, it leads to some anti-patterns like the infamous "catch throw" and obfuscates the real problems. For more information on that see a blog post I made on the subject.

In terms of your problem, you can turn on first chance debugging for only a specific type of exception. This should work well unless the other exceptions are of the same type.

Nate Zaugg
I recommend you implement warning exceptions and fatal exceptions grouped by function you can turn on/off only the ones you want to trap. I think think exceptions shouldn't be used just used correctly!My problem is I didn't write all the code that generates exceptions and they use general exceptions everywhere so it is hard to differentiate.
Tony Lambert
A: 

You could also use asserts instead of breakpoints. For instance, if you only want to breakpoint on the 5th iteration of a loop on the second time you call that function, you could do:

bool breakLoop = false;

...
    Work(); // Will not break on 5th iteration.
    breakLoop = true;
    Work(); // Will break on 5th iteration.
...

public void Work() {
    for(int i=0 ; i < 10 ; i++) {
        Debug.Assert (!(breakLoop && i == 5));
        ...
    }
}

So in the first call to Work, while breakLoop is false, the loop will run through without asserting, the second time through the loop will break.

Mark Booth
You can use the Hit Count feature on regular breakpoints to accomplish this without code as well.
Jeremy
True, for half of what I was demostrating, but I was trying to demonstrate a general principal of using configuration variables as well as conditions to determine when asserts are fired.
Mark Booth