Debug.Assert 与特定抛出的异常

Question

我刚刚开始浏览 John Robbins 的《调试 MS .Net 2.0 应用程序》，并且对他对 Debug.Assert(...) 的宣讲感到困惑。

他指出，良好实现的断言在某种程度上存储了错误条件的状态，例如：

Debug.Assert(i > 3, "i > 3", "This means I got a bad parameter");

现在，就我个人而言，他如此喜欢在没有实际合理的“业务逻辑”注释的情况下重述他的测试，这对我来说似乎很疯狂，也许“我由于 flobittyjam widgitification 过程，<= 3 绝不能发生”。

所以，我认为我将断言视为一种低级的“让我们保护我的假设”之类的东西......假设人们觉得这是一个只需要在调试中进行的测试 - 即你正在保护自己免受同事的侵害和未来的程序员，并希望他们能够真正进行测试。

但我不明白的是，他接着说，除了正常的错误处理之外，你还应该使用断言； 现在我的设想是这样的：

Debug.Assert(i > 3, "i must be greater than 3 because of the flibbity widgit status");
if (i <= 3)
{
    throw new ArgumentOutOfRangeException("i", "i must be > 3 because... i=" + i.ToString());
}

通过错误条件测试的 Debug.Assert 重复我得到了什么？ 我想如果我们谈论的是一个非常重要的计算的仅调试双重检查，我会得到它......

double interestAmount = loan.GetInterest();
Debug.Assert(debugInterestDoubleCheck(loan) == interestAmount, "Mismatch on interest calc");

但是我没有得到它用于肯定值得检查的参数测试（在调试和发布中）构建）...或不。 我缺少什么？

Answer 1

断言与异常抛出之间存在通信方面的问题。

假设我们有一个带有 Name 属性和 ToString 方法的 User 类。

如果 ToString 是这样实现的：

public string ToString()
{
     Debug.Assert(Name != null);
     return Name;
}

它表示 Name 永远不应该为 null，如果是，则 User 类中存在错误。

如果 ToString 是这样实现的：

public string ToString()
{
     if ( Name == null )
     {
          throw new InvalidOperationException("Name is null");
     }

     return Name;
}

如果 Name 为 null，则表示调用者错误地使用了 ToString，并且应该在调用之前进行检查。

两者的实现都

public string ToString()
{
     Debug.Assert(Name != null);
     if ( Name == null )
     {
          throw new InvalidOperationException("Name is null");
     }

     return Name;
}

表明，如果 Name 为 null，则 User 类中存在错误，但我们无论如何都想处理它。 （用户在拨打电话之前不需要检查姓名。）我认为这就是罗宾斯推荐的那种安全措施。

Answer 2

当涉及到提供关于测试问题的调试与断言的指导时，我已经思考了很长时间。

您应该能够使用错误的输入、错误的状态、无效的操作顺序和任何其他可能的错误条件来测试您的类，并且断言应该永远跳闸。 每个断言都会检查某些内容应该始终为真，无论执行的输入或计算如何。

我得出的良好经验法则是：

1. 断言不能替代独立于配置而正确运行的健壮代码。 它们是互补的。

2. 在单元测试运行期间决不应该触发断言，即使在输入无效值或测试错误条件时也是如此。 代码应该在不发生断言的情况下处理这些情况。

3. 如果断言失败（无论是在单元测试中还是在测试期间），则该类被窃听。

对于所有其他错误——通常是由于环境（网络连接丢失）或误用（调用者传递了空值）——使用硬检查和错误检查会更好、更容易理解。 例外情况。 如果发生异常，调用者知道这可能是他们的错。 如果发生断言，调用者就知道这可能是断言所在代码中的错误。

关于重复：我同意。 我不明白为什么您要使用 Debug.Assert 和异常检查来复制验证。 它不仅给代码增加了一些噪音，让谁有错的问题变得更加混乱，而且是一种重复。

Answer 3

良好使用 Assert 的示例：

Debug.Assert(flibbles.count() < 1000000, "too many flibbles"); // indicate something is awry
log.warning("flibble count reached " + flibbles.count()); // log in production as early warning

我个人认为，当您知道某些内容超出了所需限制时，才应该使用 Assert，但您可以确定继续是相当安全的。 在所有其他情况下（请随意指出我没有想到的情况）使用异常来快速失败。

对我来说，关键的权衡是您是否想要通过异常来关闭实时/生产系统以避免损坏并使故障排除更容易，或者您是否遇到了一种情况，这种情况永远不应该允许在测试/调试版本中继续被忽视，但可以允许继续生产（当然会记录警告）。

比照。 http://c2.com/cgi/wiki?FailFast
从java问题复制并修改：异常与断言

Answer 4

IMO 这只是开发时间的损失。 正确实施的异常可以让您清楚地了解发生的情况。 我看到太多应用程序显示模糊的“断言失败：i < 10”错误。 我认为断言是一个临时解决方案。 在我看来，程序的最终版本中不应包含任何断言。 在我的实践中，我使用断言进行快速和肮脏的检查。 代码的最终版本应考虑错误情况并做出相应的行为。 如果发生不好的事情，你有两个选择：处理它或离开它。 如果传入错误的参数，函数应该抛出带有有意义描述的异常。我认为验证逻辑没有重复。

Answer 5

断言不用于参数检查。 应始终进行参数检查（并且精确地根据文档和/或规范中指定的前提条件），并根据需要抛出 ArgumentOutOfRangeException 。

断言用于测试“不可能”的情况，即您（在程序逻辑中）假设的事情是正确的。 这些断言是为了告诉您这些假设是否因任何原因而被打破。

希望这可以帮助！

Answer 6

这里是 2 美分。

我认为最好的方法是同时使用断言和异常。 恕我直言，这两种方法之间的主要区别是，如果断言语句可以轻松地从应用程序文本中删除（定义、条件属性...），而抛出的异常则依赖于（通常）条件代码，而条件代码更难删除（带有预处理器条件的多个部分）。

每个应用程序异常都应得到正确处理，而断言仅应在算法开发和测试期间得到满足。

如果将空对象引用作为例程参数传递，并且使用该值，则会出现空指针异常。 事实上：为什么你应该写一个断言？ 在这种情况下这是浪费时间。
但是类例程中使用的私有类成员又如何呢？ 当这些值在某处设置时，最好使用断言检查是否设置了空值。 那只是因为当您使用该成员时，您会遇到空指针异常，但您不知道该值是如何设置的。 这会导致程序重新启动，破坏所有用于设置私有成员的入口点。

异常更有用，但管理它们（恕我直言）可能非常繁重，并且有可能使用太多异常。 而且它们需要额外的检查，可能不希望优化代码。
就我个人而言，我仅在代码需要深度 catch 控制（catch 语句在调用堆栈中非常低）或函数参数未硬编码在代码中时才使用异常。

Answer 7

异常可以被捕获并吞掉，从而使错误对测试不可见。 Debug.Assert 不会发生这种情况。

没有人应该有一个捕获所有异常的 catch 处理程序，但人们无论如何都会这样做，有时这是不可避免的。 如果您的代码是从 COM 调用的，则互操作层会捕获所有异常并将它们转换为 COM 错误代码，这意味着您不会看到未处理的异常。 断言不会受此影响。

此外，当异常未得到处理时，更好的做法是进行小型转储。 VB 比 C# 更强大的一个领域是，您可以使用异常过滤器在异常发生时捕获小型转储，并保持异常处理的其余部分不变。 Gregg Miskelly 关于异常过滤器注入的博客文章 提供了一种在 C# 中执行此操作的有用方法。

关于资产的另一注释...它们与代码中的错误条件单元测试的交互很差。 有一个包装器来关闭单元测试的断言是值得的。

Answer 8

我使用显式检查，在公共和受保护方法上抛出异常，并在私有方法上抛出断言。

通常，显式检查可以防止私有方法看到不正确的值。 所以实际上，断言正在检查一个不可能的条件。 如果断言确实触发，它会告诉我该类的公共例程之一中包含的验证逻辑存在缺陷。