c# - Debug.Assert 与异常抛出

Question

我读了很多 articles (以及 StackOverflow 上发布的其他几个类似问题)关于如何以及何时使用断言，我非常理解它们。但是，我仍然不明白什么样的动机应该促使我使用 Debug.Assert 而不是抛出一个普通的异常。我的意思是，在 .NET 中，对失败断言的默认响应是“停止世界”并向用户显示一个消息框。尽管可以修改这种行为，但我发现它非常烦人且多余要做到这一点，虽然我可以改为抛出一个合适的异常。这样，我可以在抛出异常之前轻松地将错误写入应用程序的日志，而且，我的应用程序不一定会卡住。

那么，我为什么要使用 Debug.Assert 而不是普通异常？将断言放在不应该的地方可能只会导致各种“不需要的行为”，所以在我看来，使用断言而不是抛出异常并没有什么好处。你同意我的看法吗，还是我遗漏了什么？

注意:我完全理解“理论上”的区别(调试与发布、使用模式等)，但在我看来，我最好抛出异常而不是抛出异常执行断言。因为如果在生产版本中发现错误，我仍然希望“断言”失败(毕竟，“开销”小得离谱)，所以我最好抛出异常。

---

编辑: 在我看来，如果断言失败，则意味着应用程序进入了某种损坏的、意外的状态。那我为什么要继续执行呢？应用程序是在调试版本还是发布版本上运行并不重要。两者都一样

Answer 1

尽管我同意您的推理似是而非——也就是说，如果一个断言被意外违反，通过抛出来停止执行是有意义的——我个人不会使用异常来代替断言。原因如下:

正如其他人所说，断言应该记录不可能的情况，这样一来，如果据称不可能的情况发生，开发人员就会得到通知。相比之下，异常为异常的、不太可能的或错误的情况提供了一种控制流机制，但并非不可能的情况。对我来说，主要区别在于:

• 应该始终可以生成一个测试用例来执行给定的 throw 语句。如果不可能生成这样的测试用例，那么您的程序中就有一个永远不会执行的代码路径，应该将其作为死代码删除。

• 永远不可能生成导致断言触发的测试用例。如果断言触发，要么是代码错误，要么是断言错误；无论哪种方式，都需要更改代码。

这就是为什么我不会用异常替换断言的原因。如果断言实际上无法触发，则用异常替换它意味着您的程序中有不可测试的代码路径。我不喜欢不可测试的代码路径。