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

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

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应该始终为真!

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

您应该使用Debug。断言来测试程序中的逻辑错误。编译器只能通知您语法错误。因此，您肯定应该使用Assert语句来测试逻辑错误。比如测试一个销售汽车的项目，只有蓝色的宝马可以得到15%的折扣。编译器不能告诉你你的程序在执行这个操作时逻辑上是否正确，但是assert语句可以。

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

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

我已经在这里阅读了答案，我认为我应该添加一个重要的区别。使用断言有两种非常不同的方式。一种是作为临时的开发人员快捷方式，表示“这不应该真的发生，所以如果它发生了，就告诉我，这样我就可以决定怎么做”，有点像一个条件断点，用于你的程序能够继续的情况。另一种方法是在代码中假设有效的程序状态。

在第一种情况下，断言甚至不需要出现在最终代码中。您应该使用Debug。在开发期间断言，如果/当不再需要时，您可以删除它们。如果你想要保留它们或者忘记删除它们，没有问题，因为它们在发布汇编中不会有任何后果。

But in the second case, the assertions are part of the code. They, well, assert, that your assumptions are true, and also document them. In that case, you really want to leave them in the code. If the program is in an invalid state it should not be allowed to continue. If you couldn't afford the performance hit you wouldn't be using C#. On one hand it might be useful to be able to attach a debugger if it happens. On the other, you don't want the stack trace popping up on your users and perhaps more important you don't want them to be able to ignore it. Besides, if it's in a service it will always be ignored. Therefore in production the correct behavior would be to throw an Exception, and use the normal exception handling of your program, which might show the user a nice message and log the details.

跟踪。Assert有实现这一点的完美方法。它不会在生产环境中被删除，并且可以使用app.config配置不同的侦听器。 因此，对于开发来说，默认的处理程序就可以了，对于生产来说，您可以创建一个简单的TraceListener(如下所示)，它会抛出一个异常并在生产配置文件中激活它。

using System.Diagnostics;

public class ExceptionTraceListener : DefaultTraceListener
{
    [DebuggerStepThrough]
    public override void Fail(string message, string detailMessage)
    {
        throw new AssertException(message);
    }
}

public class AssertException : Exception
{
    public AssertException(string message) : base(message) { }
}

在产品配置文件中:

<system.diagnostics>
  <trace>
    <listeners>
      <remove name="Default"/>
      <add name="ExceptionListener" type="Namespace.ExceptionTraceListener,AssemblyName"/>
    </listeners>
  </trace>
 </system.diagnostics>