如果我在 catch 中添加一个只有 Debugger.Break() 的 try-catch 块答案

【问题标题】：If I add a try-catch block with just Debugger.Break() in catch如果我在 catch 中添加一个只有 Debugger.Break() 的 try-catch 块
【发布时间】：2011-10-10 21:00:33
【问题描述】：

...它会在发布版本中有效地变成一个空的try-catch吗？

或者它永远不会构建？

try
{
   // do stuff...
   // do stuff...
}
catch
{
    Debugger.Break();
}

我知道不会包含 Debugger 调用 - 很明显，但这是否也适用于我包裹它的 catch？

这是一件坏事吗？这只是为了调试目的——我想在它发生的地方看到异常，而不是在它冒泡堆栈后离开我的地方。只是更方便。

【问题讨论】：

您应该在catch 中throw 无论如何，即使在Break() 之后也是如此
“我知道不会包含调试器调用——显然”，这是不正确的。确实，当设置了DEBUG 常量时，Debug.xxx 调用不包括在内，但Debugger.xxx 调用总是包括。这是有道理的，因为否则您将如何强行导致发布版本中断？如果您只想在调试版本中使用它，请将其包装在一个方法中并将Conditional("DEBUG") 添加到属性中。此外，Debugger.Launch() 可能更适合您的场景。
所以，基本上，答案是 不，它不会导致一个空的 catch 块（它不会在发布版本中做你所期望的，它将显示 WER 崩溃对话框...）。

标签： c# debugging exception release try-catch

【解决方案1】：

这将导致一个空的 catch 块。为避免这种情况，您可以使用条件编译序列：

private void DoSomething()
{
#if DEBUG
    try
    {
#endif
        //do something
#if DEBUG
    }
    catch
    {
        Debugger.Break();
        throw;
    }
#endif
}

【讨论】：

这改变了意思；原来的不抛出。
它不会产生一个空的catch块，Debugger.Break()是一个指令。

【解决方案2】：

或者您可能更喜欢这个版本：

private void DoSomething() 
{ 
  try     
  { 
    //do something 
  }     
  catch     
  {
#if DEBUG
    Debugger.Break();
#else
    throw;  // throws the exception using original call stack.
#endif
  }
}

【讨论】：

【解决方案3】：

如果你这样做，它会在调试模式下中断，并在发布模式下忽略捕获的异常。这完全等同于在释放模式下消失的 catch 上放置一个断点。就像在释放模式下有一个空的 catch 块一样。

【讨论】：

【解决方案4】：

不是直接回答您的问题，但您知道 Visual Studio 内置了在发生异常时直接中断的功能吗？

您可以在Debug->Exceptions（或Ctrl+Alt+E）下找到该功能

在http://stevesmithblog.com/blog/visual-studio-break-when-exception-thrown/ 上查看更多信息。

【讨论】：

这个功能太棒了；）更容易找到罪魁祸首。
感谢您的提示！我的同事也不知道。非常方便 - 虽然，当我设置它并再次启动我们继承的应用程序时，我被它默默吞下的异常数量所击倒（例如（可能）在尝试访问所有进程以确定它是否存在时（可能）数百个 Win32Exceptions是唯一运行的程序实例吗！？）；）
如果程序处理异常并从异常中恢复，可能需要一些时间来调整设置以免中断恢复的异常，但我认为这通常是值得的。
是的，我相信。但是还是；在这种情况下，引发如此多的异常可能是一个糟糕的设计（为了一次强制执行不超过一个实例，可以只使用 Mutex 对象 afaik）。因此，必须在每一个异常情况下都停下来实际上有助于让这些事情曝光