根据设计标准，你应该

坚持每一个假设。平均每五行就有一个断言。

using System.Diagnostics;

object GetObject()
{...}

object someObject = GetObject();
Debug.Assert(someObject != null);

作为一个免责声明，我应该提到我还没有发现实现这个IRL是实际的。但这是他们的标准。

我想再添加四种情况，其中Debug。断言可以是正确的选择。

1)我在这里没有看到提到的是assert在自动化测试期间可以提供的额外概念覆盖。举个简单的例子:

当作者认为他们已经扩展了代码的范围以处理额外的场景，并修改了一些高级调用者时，理想情况下(!)他们将编写单元测试来覆盖这种新情况。那么，完全集成的代码可能会表现得很好。

然而，实际上已经引入了一个微妙的缺陷，但在测试结果中没有发现。在这种情况下，被调用者变得不确定，只提供预期的结果。或者，它产生了一个未被注意到的舍入误差。或者造成的错误在其他地方被抵消。或者不仅授予所请求的访问权限，还授予不应该授予的其他特权。等。

此时，被调用者中包含的Debug.Assert()语句加上单元测试驱动的新用例(或边缘用例)可以在测试期间提供宝贵的通知，即原始作者的假设已经失效，并且在没有额外审查的情况下不应该发布代码。断言与单元测试是完美的合作伙伴。

2)此外，有些测试写起来很简单，但成本很高，而且在初始假设下是不必要的。例如:

如果一个对象只能从某个安全的入口点访问，是否应该从每个对象方法对网络权限数据库进行额外查询，以确保调用者具有权限?当然不是。也许理想的解决方案包括缓存或其他一些功能扩展，但设计并不需要这样做。当对象被附加到不安全的入口点时，Debug.Assert()将立即显示。

3)其次，在某些情况下，当以发布模式部署时，您的产品可能对其全部或部分操作没有有用的诊断交互。例如:

Suppose it is an embedded real-time device. Throwing exceptions and restarting when it encounters a malformed packet is counter-productive. Instead the device may benefit from best-effort operation, even to the point of rendering noise in its output. It also may not have a human interface, logging device, or even be physically accessible by human at all when deployed in release mode, and awareness of errors is best provided by assessing the same output. In this case, liberal Assertions and thorough pre-release testing are more valuable than exceptions.

4)最后，有些测试是不必要的，只是因为被呼叫方被认为是非常可靠的。在大多数情况下，代码的可重用性越高，在使其可靠方面投入的精力就越多。因此，对于来自调用方的意外参数，通常使用Exception，而对于来自被调用方的意外结果，则使用Assert。例如:

If a core String.Find operation states it will return a -1 when the search criteria is not found, you may be able to safely perform one operation rather than three. However, if it actually returned -2, you may have no reasonable course of action. It would be unhelpful to replace the simpler calculation with one that tests separately for a -1 value, and unreasonable in most release environments to litter your code with tests ensuring core libraries are operating as expected. In this case Asserts are ideal.

就其价值而言……我发现我的公共方法倾向于使用if () {throw;}模式，以确保方法被正确调用。我的私有方法倾向于使用Debug.Assert()。

The idea is that with my private methods, I'm the one under control, so if I start calling one of my own private methods with parameters that are incorrect, then I've broken my own assumption somewhere--I should have never gotten into that state. In production, these private asserts should ideally be unnecessary work since I am supposed to be keeping my internal state valid and consistent. Contrast with parameters given to public methods, which could be called by anyone at runtime: I still need to enforce parameter constraints there by throwing exceptions.

此外，如果某些东西在运行时不起作用(网络错误、数据访问错误、从第三方服务检索的坏数据等)，我的私有方法仍然可以抛出异常。我的断言只是为了确保我没有破坏我自己关于对象状态的内部假设。

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

将Debug.Assert()放在代码中任何需要进行完整性检查以确保不变量的地方。当编译Release版本时(即没有DEBUG编译器常量)，对DEBUG . assert()的调用将被删除，因此它们不会影响性能。

在调用Debug.Assert()之前仍然应该抛出异常。断言只是确保在开发过程中一切都如预期的那样。

您应该始终使用第二种方法(抛出异常)。

同样，如果你是在生产环境中(并且有一个发布版本)，抛出一个异常(在最坏的情况下让应用程序崩溃)比处理无效值和可能破坏客户数据(这可能要花费数千美元)要好。