.net 如果已命中断点A，则启用断点B

我经常发现自己在代码的某个地方设置了一个断点，并在命中该断点时手动启用一个或多个断点。一个典型的例子是当我调试一个单元测试时，并不关心前面的测试

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));
}

想象一下，如果

testAddZeros（）

和

testaddone（）

运行良好，但是

testAddNegativeNumber（）

。在这种情况下，在

Number result=a.add（b）处设置断点将是开始调试的自然位置。现在，假设错误位于
Number:：add
的深处，因此我们对
Numbers:：add
中早期出现的内容并不感兴趣。我想做的是在
Numbers:：add
中的某个位置设置一个断点，只有在
testAddNegativeEnumber（）
-test中时才会触发该断点

当断点
A
被点击时，有没有办法自动启用断点
B
？
这是我认为您能做的最好的方法，但这似乎是一个太大的黑客甚至无法尝试，因为它涉及到添加一个变量

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");  

实际上，您不能在Console.WriteLine（“HERE”）行上停止，但可以启用或禁用断点，这实际上会启用另一个断点

但是要小心，条件断点语句会在调试时严重降低应用程序的性能。
通过使用一些全局存储来保存启用依赖断点的标记，即使不更改代码，也可以获取依赖断点

我发现的最易访问的存储之一是应用程序域自定义属性。可以通过System.AppDomain.CurrentDomain.GetData和SetData方法访问它们

因此，在第一个断点上，您可以定义“命中时”设置：

{System.AppDomain.CurrentDomain.SetData（“break”，true）}


在依赖断点上，将命中条件设置为：

System.AppDomain.CurrentDomain.GetData（“中断”）！=空的

你检查过条件断点吗？可能您可以使用断点A被命中的条件来启用“条件”断点B（在这种情况下，您可能不再需要断点A）@ChristiaanV:是的，但我担心条件断点在这种情况下是不够的-至少在一般情况下是不够的。您能展示一个代码示例吗，我能想到的唯一一件事就是使用反射来查找在条件断点内调用的方法。类似这样的东西：new StackTrace（）.GetFrame（1.GetMethod（）.Name==“TestAddNegativeEnumber”虽然这不是我想要的，但我想这是最好的（好的，唯一的）建议。我想知道这类东西是否适用于跟踪点。。。现在我知道了。向上投票！在调试C++代码时，是否可以进行这项工作？