Java 正确使用断言

请您帮助我更好地理解“断言”与“抛出异常”的恰当用法是什么？每个场景何时合适

情景1

代码

试验

场景2

代码

试验

---

与assert的主要区别是

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

assert更适合于将在生产中关闭的测试

如果您想要一个每次都被检查的测试，特别是在验证输入数据时，您应该使用每次都运行的检查。

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

Assert是在对应用程序进行调试时使用的东西，比如当您必须检查数学表达式是否真的为您提供了适当的值，或者对象/结构成员是否为null或缺少重要的内容，等等

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

---

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

当不满足条件会破坏程序的完整性时，应该使用assert关键字。这些是不可恢复的错误情况

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

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

@Test(expected=MyException.class)

---

在测试代码之外，断言通常是一个坏主意。原因是，除非有非常严格的公司指导方针，否则最终总是混合使用，这是不好的。断言基本上有两种使用场景：

额外的，可能是缓慢的测试，将在生产中关闭

不应禁用的正常、快速代码健全性测试（如要求给定的方法参数为非null）

只要您始终遵循其中一种方案，一切都会很好。但是，如果您的代码库最终同时出现两种方案，那么您就会陷入困境。您不想禁用方案2之后的断言，以及方案1之后的断言（并且会减慢您的生产代码）你想禁用的。怎么办

---

我使用过的大多数代码库都在普通代码中使用了断言，但最终都没有因为这个原因在生产构建中禁用它们。因此，我的建议始终是在测试代码之外避免它们。对普通代码使用普通异常，并坚持使用额外的、可能较慢的代码（使用断言）在单独的测试代码中。

您无法捕获null异常。assertNotNull（e）必须为true。您是否使用JUnit 4？如果是，请使用

@test（expected=IllegalArgumentException.class）

注释，而不是在测试方法中使用

try

/

catch

。以及fail（）；或者考试可能因为错误的原因而通过。@asph-好的观点。我完全忘记了这一点。Thx@Peter.问题不在于assertNotNull，而在于使用通用Java的“assert”语句，而不是编写一个“if”条件，在该条件下，如果失败，将引发异常

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

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);
  }
}

@Test(expected=MyException.class)