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

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

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

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

简而言之

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

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)检查包括:

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

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

我想再添加四种情况，其中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.

摘自《实用程序员:从熟练工到高手》

Leave Assertions Turned On There is a common misunderstanding about assertions, promulgated by the people who write compilers and language environments. It goes something like this: Assertions add some overhead to code. Because they check for things that should never happen, they'll get triggered only by a bug in the code. Once the code has been tested and shipped, they are no longer needed, and should be turned off to make the code run faster. Assertions are a debugging facility. There are two patently wrong assumptions here. First, they assume that testing finds all the bugs. In reality, for any complex program you are unlikely to test even a miniscule percentage of the permutations your code will be put through (see Ruthless Testing). Second, the optimists are forgetting that your program runs in a dangerous world. During testing, rats probably won't gnaw through a communications cable, someone playing a game won't exhaust memory, and log files won't fill the hard drive. These things might happen when your program runs in a production environment. Your first line of defense is checking for any possible error, and your second is using assertions to try to detect those you've missed. Turning off assertions when you deliver a program to production is like crossing a high wire without a net because you once made it across in practice. There's dramatic value, but it's hard to get life insurance. Even if you do have performance issues, turn off only those assertions that really hit you.