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的技巧。

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

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

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

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

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

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

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

简而言之

断言用于保护和检查契约式设计约束，即确保代码、对象、变量和参数的状态在预期设计的边界和限制内运行。

Asserts should be for Debug and non-Production builds only. Asserts are typically ignored by the compiler in Release builds. Asserts can check for bugs / unexpected conditions which ARE in the control of your system Asserts are NOT a mechanism for first-line validation of user input or business rules Asserts should not be used to detect unexpected environmental conditions (which are outside the control of the code) e.g. out of memory, network failure, database failure, etc. Although rare, these conditions are to be expected (and your app code cannot fix issues like hardware failure or resource exhaustion). Typically, exceptions will be thrown - your application can then either take corrective action (e.g. retry a database or network operation, attempt to free up cached memory), or abort gracefully if the exception cannot be handled. A failed Assertion should be fatal to your system - i.e. unlike an exception, do not try and catch or handle failed Asserts - your code is operating in unexpected territory. Stack Traces and crash dumps can be used to determine what went wrong.

断言有巨大的好处:

帮助查找用户输入的缺失验证，或高级代码中的上游错误。 代码库中的断言清楚地向读者传达了代码中所做的假设 Assert将在调试版本的运行时进行检查。 一旦对代码进行了详尽的测试，将代码重新构建为Release将消除验证假设的性能开销(但好处是，如果需要，后面的Debug构建将始终恢复检查)。

．.． 更详细地

Debug.Assert expresses a condition which has been assumed about state by the remainder of the code block within the control of the program. This can include the state of the provided parameters, state of members of a class instance, or that the return from a method call is in its contracted / designed range. Typically, asserts should crash the thread / process / program with all necessary info (Stack Trace, Crash Dump, etc), as they indicate the presence of a bug or unconsidered condition which has not been designed for (i.e. do not try and catch or handle assertion failures), with one possible exception of when an assertion itself could cause more damage than the bug (e.g. Air Traffic Controllers wouldn't want a YSOD when an aircraft goes submarine, although it is moot whether a debug build should be deployed to production ...)

什么时候应该使用断言?

At any point in a system, or library API, or service where the inputs to a function or state of a class are assumed valid (e.g. when validation has already been done on user input in the presentation tier of a system, the business and data tier classes typically assume that null checks, range checks, string length checks etc on input have been already done). Common Assert checks include where an invalid assumption would result in a null object dereference, a zero divisor, numerical or date arithmetic overflow, and general out of band / not designed for behaviour (e.g. if a 32 bit int was used to model a human's age, it would be prudent to Assert that the age is actually between 0 and 125 or so - values of -100 and 10^10 were not designed for).

.Net代码契约 在. net堆栈中，代码契约可以作为Debug.Assert的补充，也可以作为Debug.Assert的替代。代码契约可以进一步形式化状态检查，并且可以帮助在编译时(或者稍后，如果在IDE中作为背景检查运行)检测违反假设的情况。

契约式设计(DBC)检查包括:

合同。要求-约定的先决条件 合同。保证-合同后置条件 不变量——表示关于对象在其生命周期中所有点的状态的假设。 合同。当调用非契约装饰方法时，假定-安抚静态检查器。