Debug.Assert与异常抛出

我已经阅读了很多有关如何以及何时使用断言的文章（以及在StackOverflow上发布的其他一些类似问题），并且我对它们很了解。但是，我仍然不明白应该用哪种动机来促使我使用它，Debug.Assert而不是抛出一个明显的例外。我的意思是，在.NET中，对失败的断言的默认响应是“停止运行”并向用户显示消息框。尽管可以修改这种行为，但我发现这样做非常烦人和多余，而我可以抛出一个适当的异常。这样，在抛出异常之前，我可以轻松地将错误写入应用程序日志，此外，我的应用程序不一定会冻结。

那么，为什么我应该使用Debug.Assert而不是普通的例外呢？将断言放置在不应该出现的位置可能会导致各种“有害行为”，因此，根据我的观点，我真的没有通过使用断言而不是抛出异常来获得任何好处。您是否同意我的意见，或者我在这里错过了什么？

注意：我完全理解“理论上”的区别（调试与发行，使用模式等），但是据我所知，我最好抛出一个异常而不是执行一个断言。由于如果在生产版本中发现了错误，我仍然希望“断言”失败（毕竟，“开销”很小），所以我最好抛出一个异常。

编辑：我认为，如果断言失败，则意味着应用程序进入某种损坏的意外状态。那我为什么要继续执行呢？应用程序是在调试版本还是发行版本上运行都没有关系。两者都一样

尽管我同意您的推理是合理的 -也就是说，如果断言被意外违反，则通过抛出中断执行是有意义的-我个人不会在断言的位置使用异常。原因如下：

正如其他人所说，主张应记录那些情况是不可能的，以这样的方式，如果涉嫌不可能的情况来传递，开发商通知。相比之下，异常为异常，不太可能或错误的情况提供了控制流机制，但并非并非不可能。对我而言，关键区别在于：

• 总是有可能产生一个执行给定throw语句的测试用例。如果不可能产生这样的测试用例，则您的程序中有一条代码路径永远不会执行，应将其作为无效代码删除。

• 绝不可能产生导致断言触发的测试用例。如果断言被触发，则代码是错误的，或者断言是错误的。无论哪种方式，都需要在代码中进行某些更改。

这就是为什么我不会用异常代替断言的原因。如果断言实际上不能触发，则用异常替换它意味着您的程序中具有不可测试的代码路径。我不喜欢无法测试的代码路径。

断言用于检查程序员对世界的理解。仅当程序员做错了什么时，断言才应该失败。例如，切勿使用断言来检查用户输入。

断言测试“不可能发生”的条件。例外情况是“不应发生但会发生”。

断言非常有用，因为在构建时（甚至在运行时），您可以更改其行为。例如，在发行版本中，断言甚至不会被检查，因为它们会引入不必要的开销。这也是要注意的一点：您的测试甚至可能不会执行。

如果使用异常而不是断言，则会失去一些价值：

1. 代码更加冗长，因为测试和引发异常至少需要两行，而断言仅是一行。

2. 您的测试和引发代码将始终运行，而断言可以被编译掉。

3. 您失去了与其他开发人员的交流，因为断言与检查和抛出的产品代码的含义不同。如果您确实在测试编程断言，请使用断言。

此处更多信息：http : //nedbatchelder.com/text/assert.html

编辑： 响应您在帖子中所做的编辑/注释：听起来，对于要尝试完成的事情类型，使用异常是优于使用断言的正确选择。我认为您遇到的心理绊脚石是您正在考虑使用异常和断言来实现相同的目的，因此您正在尝试找出使用哪种“正确”方法。尽管断言和异常的使用方式可能有所重叠，但请不要混淆它们对于同一问题的不同解决方案，而不能混淆。断言和异常各有其目的，优点和缺点。

我本来要用自己的话来输入答案，但这确实比我想象的要好得多：

C＃站：断言

使用assert语句可以是在运行时捕获程序逻辑错误的有效方法，但是很容易将它们从生产代码中过滤掉。一旦开发完成，只需在编译过程中定义预处理器符号NDEBUG [可禁用所有断言]，就可以消除这些冗余的编码错误测试的运行时成本。但是，请务必记住，放置在assert中的代码在生产版本中将被省略。

仅当以下所有条件成立时，才最好使用断言来测试条件：

* the condition should never be false if the code is correct,
* the condition is not so trivial so as to obviously be always true, and
* the condition is in some sense internal to a body of software.

断言几乎绝不应用于检测软件正常运行期间出现的情况。 例如，通常不应使用断言来检查用户输入中的错误。但是，使用断言来验证呼叫者已检查用户输入可能是有意义的。

基本上，将异常用于生产应用程序中需要捕获/处理的事物，使用断言执行逻辑检查，这将对开发有用，但在生产中已关闭。

我认为（人为的）实际示例可能有助于阐明差异：

（改编自MoreLinq的Batch扩展）

// 'public facing' method
public int DoSomething(List<string> stuff, object doohickey, int limit) {

    // validate user input and report problems externally with exceptions

    if(stuff == null) throw new ArgumentNullException("stuff");
    if(doohickey == null) throw new ArgumentNullException("doohickey");
    if(limit <= 0) throw new ArgumentOutOfRangeException("limit", limit, "Should be > 0");

    return DoSomethingImpl(stuff, doohickey, limit);
}

// 'developer only' method
private static int DoSomethingImpl(List<string> stuff, object doohickey, int limit) {

    // validate input that should only come from other programming methods
    // which we have control over (e.g. we already validated user input in
    // the calling method above), so anything using this method shouldn't
    // need to report problems externally, and compilation mode can remove
    // this "unnecessary" check from production

    Debug.Assert(stuff != null);
    Debug.Assert(doohickey != null);
    Debug.Assert(limit > 0);

    /* now do the actual work... */
}

因此，正如Eric Lippert等人所说的那样，您只能断言您期望正确的内容，以防万一您（开发人员）在其他地方不小心使用了它，以便您可以修复代码。当您无法控制或无法预料其中的内容时（例如，对于用户输入），您基本上会抛出异常，从而使任何给它的坏数据都可以适当地响应（例如，用户）。

Code Complete的另一个块：

“断言是一个函数或宏，如果假设不成立，则会大声抱怨。使用断言来记录代码中的假设并清除意外情况。...

“在开发过程中，断言消除了矛盾的假设，意想不到的条件，传递给例程的错误值等。”

他接着就应主张和不应主张的内容添加一些准则。

另一方面，例外：

“使用异常处理来引起人们对意外情况的注意。应对异常情况的方式应使其在开发期间显而易见，并在生产代码运行时可恢复。”

如果您没有这本书，则应该购买。

默认情况下，Debug.Assert仅在调试版本中起作用，因此，如果要在发行版本中捕获任何不良的不良行为，则需要使用异常或在项目属性中打开调试常量（在一般不是一个好主意）。

使用断言的事情，现在可能的，但不应该发生（如果它是不可能的，为什么你会放一个说法对吗？）。

这听起来不像是使用案例Exception吗？为什么要使用断言而不是Exception？

因为应该有在断言之前调用的代码，这将停止断言的参数为false。

通常，在您之前没有代码Exception可以保证不会将其引发。

为什么Debug.Assert()在产品中编译好了？如果您想在调试中了解它，您是否不想在产品中了解它？

您只需要在开发过程中就可以使用它，因为一旦发现Debug.Assert(false)情况，您就可以编写代码以确保Debug.Assert(false)不会再发生这种情况。一旦开发完成，假设您已找到Debug.Assert(false)情况并进行了修复，则Debug.Assert()可以安全地将其编译掉，因为它们现在是多余的。

假设您是一个相当大的团队的成员，并且有几个人都在同一通用代码库上工作，包括在类上重叠。您可以创建一个由其他几种方法调用的方法，并且为了避免锁争用，您无需向其添加单独的锁，而是“假定”该方法先前已由具有特定锁的调用方法锁定。例如，Debug.Assert（RepositoryLock.IsReadLockHeld || RepositoryLock.IsWriteLockHeld）; 其他开发人员可能会忽略注释，即调用方法必须使用锁，但他们不能忽略此注释。