Debugger.Break 有副作用吗？答案

【问题标题】：Does Debugger.Break have any side effects?Debugger.Break 有副作用吗？
【发布时间】：2019-03-03 11:46:13
【问题描述】：

System.Diagnostics.Debugger.Break(); // this DB call has not been mocked

我想将这些放在 I/O 调用站点的代码中，让单元测试开发人员知道他们何时没有正确模拟调用，但我不想产生新问题。

【问题讨论】：

1.是的。 2. 是的。或者说详细一点；） 1. 它适用于所有配置。 2. 如果尚未附加调试器，它会要求附加调试器。
如果没有附加调试器（自 .NET 4 起），您甚至不会收到异常吗？您只能在调试版本中添加它：#if DEBUG Debugger.Break(); #endif
@OverlordZurg 不符合the comments in the source。
@OverlordZurg docs.microsoft.com/en-us/dotnet/api/… "如果没有附加调试器，系统会询问用户是否要附加调试器。"
@AndyJ 没错。如果您想要甜蜜的信用，请作为答案提交

【解决方案1】：

不幸的是，您的用例确实如此。

解决您的疑虑：

Tim Schmelter 提出了一个很好的建议。如果您想将 Debugger.Break 限制为仅 Debug 构建，则可以使用 Conditional Compilation。

#if DEBUG
    Debugger.Break();
#endif

如果没有附加调试器，那么它会尝试附加调试器，或者根据您所针对的 .Net Framework 版本向 Windows 错误报告 (WER) 子系统发送消息。

如果没有附加调试器，系统会询问用户是否要附加调试器。

...

从 .NET Framework 4 开始，运行时不再严格控制启动 Break 方法的调试器，而是向 Windows 错误报告 (WER) 子系统报告错误。

【讨论】：

【解决方案2】：

正如 cmets 和 @AndyJ 的回答所解释的，如果进程没有附加调试器，您的程序将会崩溃。

您可能需要在运行时调用Debug.Break 之前检查是否附加了调试器。有一个 API 属性，System.Diagnostics.Debugger.IsAttached

【讨论】：

知道该检查对性能的影响有多大吗？最终，如果我认为有必要，我可能会创建一个新的“UnitTest”配置，但最好不必创建新配置。
@OverlordZurg，因为您在问题中提到了 I/O 站点，所以可以忽略不计。一切都比 I/O 快，除了 I/O。 :) 如果检查仅在 Debug 配置中编译，那么它们的性能可能不是问题。