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

根据设计标准，你应该

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

using System.Diagnostics;

object GetObject()
{...}

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

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

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

断言用于捕获程序员(您的)错误，而不是用户错误。只有在用户不可能触发断言时才应该使用它们。例如，如果你正在编写一个API，在API用户调用的任何方法中，都不应该使用断言来检查参数是否为空。但是它可以在一个私有方法中使用，而不是作为API的一部分公开，以断言您的代码永远不会在不应该传递null参数时传递null参数。

当我不确定时，我通常更喜欢异常而不是断言。

John Robbins在《调试Microsoft . net 2.0应用程序》一书中有一大节是关于断言的。他的主要观点是:

Assert liberally. You can never have too many assertions. Assertions don't replace exceptions. Exceptions cover the things your code demands; assertions cover the things it assumes. A well-written assertion can tell you not just what happened and where (like an exception), but why. An exception message can often be cryptic, requiring you to work backwards through the code to recreate the context that caused the error. An assertion can preserve the program's state at the time the error occurred. Assertions double as documentation, telling other developers what implied assumptions your code depends on. The dialog that appears when an assertion fails lets you attach a debugger to the process, so you can poke around the stack as if you had put a breakpoint there.

PS:如果你喜欢《代码完成》，我推荐你继续阅读这本书。我买这本书是为了学习如何使用WinDBG和转储文件，但前半部分包含了一些帮助避免bug的技巧。

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

在第一种情况下，断言甚至不需要出现在最终代码中。您应该使用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>