24

I'm often find myself setting a breakpoint A somewhere in the code and manually enabling one or more breakpoints when this breakpoint is hit. A typical case is when I'm debugging an unittest and don't care about the preceding tests.

void testAddZeros()
{
  Number a(0);
  Number b(0);
  Number result = a.add(b);
  assert((a + b) == Number(0))
}
void testAddOnes()
{
  Number a(1);
  Number b(1);
  Number result = a.add(b);
  assert((a + b) == Number(2));
}
void testAddNegativeNumber()
{
  Number a(1);
  Number b(-1)
  Number result = a.add(b);
  assert((a + b) == Number(0));
}

Imagine if testAddZeros() and testAddOnes() runs fine, but testAddNegativeNumber(). In this case setting a breakpoint at Number result = a.add(b); would be a natural place to start debugging. Now imagine that the error is located somewhere deep inside Number::add, so we're not really interrested in the stuff that occurs early in Numbers::add. What I want to do is to set a breakpoint somewhere inside Numbers::add that only triggers if I'm inside the testAddNegativeNumber()-test.

Is there any way to automatically enable breakpoint B when breakpoint A is hit?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
larsmoa
  • 12,604
  • 8
  • 62
  • 85
  • 1
    Have you checked conditional breakpoints? Probably you could use the condition on which breakpoint A is hit to enable 'conditional' breakpoint B. (In that case you mabye don't need breakpoint A anymore) – ChristiaanV Nov 14 '11 at 14:17
  • @ChristiaanV: yes, but I'm afraid conditional breakpoints won't suffice in this case - at least not in general. – larsmoa Nov 14 '11 at 14:20
  • Could you show a code sample, where you would like to use this? – ChristiaanV Nov 14 '11 at 14:23
  • Only thing that i can think of is using reflection to find the method that is calling inside the conditional breakpoint. Something like this: new StackTrace().GetFrame(1).GetMethod().Name == "testAddNegativeNumber" – ChristiaanV Nov 14 '11 at 15:40

2 Answers2

24

You can get the dependent breakpoints even without changing the code, by using some global storage to hold the marker that will enable dependent breakpoint.

One of the most accessible storages that I've found is app domain custom properties. They can be accessed by System.AppDomain.CurrentDomain.GetData and SetData methods.

So on first breakpoint you define a "when hit" setting with :

{System.AppDomain.CurrentDomain.SetData("break",true)}

breakpoint condition

On the dependent breakpoint, set hit condition to:

System.AppDomain.CurrentDomain.GetData("break") != null

alex
  • 12,464
  • 3
  • 46
  • 67
2

This is about the best I think you could do, but it seems too big of a hack to even try, because it involves adding a variable...

string breakpointToStopOn = string.Empty;
Console.WriteLine("HERE"); // You can set breakpoint A here, 
                           // with a condition (right click on the breakpoint, then selectCondition),
                           // that sets breakpointToStopOn = "A"
Console.WriteLine("B"); // and you can set your breakpoint here with this condition
                        // (breakpointToStopOn == "A");

You won't actually be able to stop on the Console.WriteLine("HERE") line, but you could enable or disable the breakpoint, which would in effect enable the other breakpoint.

Beware though, conditional breakpoint statements will seriously degrade performance of your app while debugging.

Daryl
  • 18,592
  • 9
  • 78
  • 145