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?
To set a conditional breakpoint, activate the context menu in the source pane, on the line where you want the breakpoint, and select “Add Conditional Breakpoint”. You'll then see a textbox where you can enter the expression. Press Return to finish.
To set a breakpoint in source code, click in the far left margin next to a line of code. You can also select the line and press F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert breakpoint. The breakpoint appears as a red dot in the left margin.
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)}
On the dependent breakpoint, set hit condition to:
System.AppDomain.CurrentDomain.GetData("break") != null
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With