正确使用断言

Question

您能否帮助我更好地理解“断言”与“引发异常”的正确用法是什么？每种场景什么时候合适？

场景 1

代码

public Context(Algorythm algo) {
  if (algo == null) {
      throw new IllegalArgumentException("Failed to initialize Context");
  }
  this.algo = algo;
}

测试

public void testContext_null() {
  try {
      context = new Context(null);
      fail();
  } catch (IllegalArgumentException e) {
      assertNotNull(e);
  }
}

场景 2

代码

public Context(Algorythm algo) {
  assert (algo != null);
  this.algo = algo;
}

测试

public void testContext_null() {
  try {
      context = new Context(null);
      fail();
  } catch (AssertionFailedError e) {
      assertNotNull(e);
  }
}

Answer 1

与断言的主要区别是；

• 按类/包打开/关闭选定测试的能力。
• 抛出的错误。

断言更适合在生产中关闭的测试。

如果您想要每次都检查的测试，尤其是验证输入中的数据，则应该使用每次运行的检查。

Answer 2

Assert 是一个宏（在 C/C++ 中，或在其他语言中是函数），用于验证给定表达式为 true 或 false，并在值为 false 时引发异常。

断言是在调试应用程序时使用的，例如当您必须检查数学表达式是否确实为您提供了适当的值，或者对象/结构成员是否不为空或缺少重要的内容等时。

异常抛出更多的是一种真正的错误处理。异常也是错误，可以停止您的应用程序，但它们被用作（比方说）应用程序的“零售版本”错误处理。这是因为可以用一些非技术消息而不是符号和内存地址来捕获异常并以不同的方式呈现给用户，而您可以将其序列化到应用程序日志中。

另一方面，断言只会停止正在运行的进程，并给您一条消息，例如“在 source_file.ext，第 X 行上断言失败。该进程将被终止”。这对用户来说并不友好:)

Answer 3

当未能满足条件而违反了程序的完整性时，应使用assert 关键字。这些是不可恢复的错误情况。

另一方面，异常会向调用方法发出错误的存在和位置的警报，但可以由程序员自行决定处理或忽略。

测试时，如果必须满足条件才能通过测试，则应使用 Assert 函数。如果您期望在该特定测试中出现异常，JUnit 4 有一个注释来表示测试应该抛出特定异常：

@Test(expected=MyException.class)

Answer 4

在测试代​​码之外，断言通常不是一个好主意。原因是，除非有非常的公司指导方针，否则最终总是会出现混合使用，这是很糟糕的。断言基本上有 2 个使用场景：

1. 额外的、可能很慢的测试，这些测试将在生产中关闭
2. 正常、快速的代码健全性测试，永远不应该被禁用（比如要求给定的方法参数为非空）

只要你总是按照其中一种情况，一切都很好。但是，如果您的代码库最终出现这两种情况，那么您就会陷入困境。您不想禁用遵循场景 2 的断言，并且您想要禁用遵循场景 1 的断言（并且会减慢生产代码）。该怎么办？

我使用过的大多数代码库在正常代码中使用了断言，但由于这个原因，从未最终在生产版本中禁用它们。因此，我的建议始终是在测试代码之外避免使用它们。对正常代码使用正常异常，并将额外的、可能较慢的代码（带断言）放在单独的测试代码中。