仅在希望为发布版本删除检查的情况下使用断言。请记住，如果不在调试模式下编译，断言将不会触发。

对于检查为空的示例，如果这是在仅限内部的API中，我可能会使用断言。如果它在一个公共API中，我肯定会使用显式检查和抛出。

使用断言检查开发人员的假设，使用异常检查环境的假设。

仅在希望为发布版本删除检查的情况下使用断言。请记住，如果不在调试模式下编译，断言将不会触发。

对于检查为空的示例，如果这是在仅限内部的API中，我可能会使用断言。如果它在一个公共API中，我肯定会使用显式检查和抛出。

如果您希望在生产代码中使用断言(即发布构建)，您可以使用Trace。Assert而不是Debug.Assert。

这当然会增加生产可执行文件的开销。

此外，如果您的应用程序在用户界面模式下运行，则默认情况下将显示断言对话框，这可能会让您的用户感到不安。

您可以通过删除DefaultTraceListener来覆盖这种行为:查看Trace的文档。MSDN中的侦听器。

总之,

使用调试。自由断言，以帮助在调试版本中捕获错误。 如果你使用Trace。在用户界面模式下断言，您可能希望删除DefaultTraceListener以避免让用户感到不安。 如果你测试的条件是你的应用程序无法处理的，你可能最好抛出一个异常，以确保执行不会继续。请注意，用户可以选择忽略断言。

我不会在产品代码中使用它们。抛出异常，捕获和记录。

在asp.net中也需要小心，因为断言可以显示在控制台上并冻结请求。

在我的书里几乎从来没有。 在绝大多数情况下，如果你想检查一切是否正常，那么就扔掉。

我不喜欢的是，它使调试构建在功能上与发布构建不同。如果调试断言失败，但功能在发布中工作，那么这有什么意义呢?如果断言者早已离开公司，没有人知道这部分代码，那就更好了。然后你就得花点时间去探索这个问题，看看它是不是真的是个问题。如果这是一个问题，那为什么那个人不第一时间扔呢?

对我来说，这建议使用调试。声称你把问题推给别人，自己解决问题。如果某件事应该是这样，但事实并非如此，那就扔掉。

我猜可能有一些性能关键的场景，你想要优化你的断言，它们在那里很有用，但是我还没有遇到这样的场景。