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

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

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

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

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

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

就其价值而言……我发现我的公共方法倾向于使用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.

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

我不知道它在c#和。net中是怎样的，但在C中assert()只在使用- ddebug编译时工作-如果没有编译，最终用户将永远不会看到assert()。仅供开发人员使用。我经常使用它，它有时更容易跟踪错误。

所有的断言应该是代码，可以优化为:

Debug.Assert(true);

因为它检验的是你已经假设为真的东西。例如:

public static void ConsumeEnumeration<T>(this IEnumerable<T> source)
{
  if(source != null)
    using(var en = source.GetEnumerator())
      RunThroughEnumerator(en);
}
public static T GetFirstAndConsume<T>(this IEnumerable<T> source)
{
  if(source == null)
    throw new ArgumentNullException("source");
  using(var en = source.GetEnumerator())
  {
    if(!en.MoveNext())
      throw new InvalidOperationException("Empty sequence");
    T ret = en.Current;
    RunThroughEnumerator(en);
    return ret;
  }
}
private static void RunThroughEnumerator<T>(IEnumerator<T> en)
{
  Debug.Assert(en != null);
  while(en.MoveNext());
}

在上面，有三种不同的空参数方法。第一个接受它为允许的(它只是什么都不做)。第二个则抛出异常供调用代码处理(或不处理，导致错误消息)。第三种假设它不可能发生，并断言它是这样的。

在第一种情况下，没有问题。

在第二种情况下，调用代码有一个问题——它不应该用null调用GetFirstAndConsume，所以它会返回一个异常。

在第三种情况下，这段代码有一个问题，因为在调用它之前，它应该已经检查过en != null，所以它不是真的是一个错误。或者换句话说，它应该是理论上可以优化为Debug.Assert(true)的代码，sicne en != null应该始终为真!

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

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