我不知道Java中这个特性背后的历史。但是我有一个关于断言可以用来做什么的想法，我认为在这个帖子中没有提到过。

假设你有一个枚举，你打开它:(†)

public enum Veggie {
    CAULIFLOWER,
    CARROT,
}

// Another class
switch (veggie) {
    case CAULIFLOWER: value = 5;
    case CARROT: value = 3;
}

†:也许优秀的Java编译器/工具会静态地捕获丢失的枚举值。在这种情况下，想象一下你发现了一些bug并修复了它。然后，您可以使用下面描述的技术在代码中适当地添加回归测试。

这里没有好的默认情况。所以你要确保你覆盖了所有的值。当你添加一个新的enum变量时，你要确保你更新了switch块:

public enum Veggie {
    CAULIFLOWER,
    CARROT,
    TOMATO,
}

但事实证明，当用户在web应用程序中加载特定视图时，这段代码会被调用。尽管存在这个错误，视图仍然可以持续存在:这将是一个bug，但不值得干扰视图的加载(让我们说用户只是看到了一些错误的数字)。所以你只需要记录一个警告:

switch (veggie) {
    case CAULIFLOWER: value = 5;
    case CARROT: value = 3;
    default: nonExhaustiveMatchOnEnum();
// […]
public static void nonExhaustiveMatchOnEnum() {
    String errorMessage: "Missing veggie";
    logger.warn(errorMessage);
}

但是当你在开发代码时，你确实希望这个错误立即失败——开发者可以在五分钟内修复这个错误，而不像你的web应用程序的用户。

所以你可以添加一个assert false:

public static void nonExhaustiveMatchOnEnum() {
    String errorMessage: "Missing veggie";
    assert false : errorMessage;
    logger.warn(errorMessage);
}

现在，应用程序将在本地崩溃，但只在生产中记录一个警告(假设您在本地使用java -ea，而不是在生产中)。

断言是用于捕获代码中的错误的开发阶段工具。它们被设计为易于删除，因此它们不会存在于生产代码中。因此断言不是您交付给客户的“解决方案”的一部分。它们是内部检查，以确保你所做的假设是正确的。最常见的例子是测试是否为空。很多方法都是这样写的:

void doSomething(Widget widget) {
  if (widget != null) {
    widget.someMethod(); // ...
    ... // do more stuff with this widget
  }
}

在这样的方法中，小部件通常不应该是空的。所以如果它是空的，在你的代码中有一个bug，你需要追踪。但是上面的代码永远不会告诉你这一点。因此，在编写“安全”代码的善意努力中，您也隐藏了一个错误。这样写代码会更好:

/**
 * @param Widget widget Should never be null
 */
void doSomething(Widget widget) {
  assert widget != null;
  widget.someMethod(); // ...
    ... // do more stuff with this widget
}

这样，您一定能尽早发现这个错误。(在合同中指定这个参数永远不应该为空也是有用的。)在开发过程中测试代码时，一定要打开断言。(说服你的同事这样做通常也很困难，我觉得这很烦人。)

现在，您的一些同事会反对这段代码，认为您仍然应该放入null检查，以防止生产中出现异常。在这种情况下，断言仍然有用。你可以这样写:

void doSomething(Widget widget) {
  assert widget != null;
  if (widget != null) {
    widget.someMethod(); // ...
    ... // do more stuff with this widget
  }
}

这样，您的同事就会高兴地看到产品代码有空检查，但在开发过程中，当小部件为空时，您就不再隐藏错误了。

这里有一个真实的例子:我曾经写过一个方法，比较两个任意值是否相等，其中任何一个值都可以为空:

/**
 * Compare two values using equals(), after checking for null.
 * @param thisValue (may be null)
 * @param otherValue (may be null)
 * @return True if they are both null or if equals() returns true
 */
public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
  } else {
    result = thisValue.equals(otherValue);
  }
  return result;
}

这段代码在thisValue不为空的情况下委托equals()方法的工作。但它假设equals()方法通过正确处理空参数正确地实现了equals()的契约。

一位同事反对我的代码，告诉我我们的许多类都有不测试null的equals()方法，所以我应该把这个检查放到这个方法中。这是否是明智的，或者我们是否应该强制错误，这样我们就可以发现并修复它，这是有争议的，但我听从了我同事的意见，放入了一个空检查，我已经标记了一个注释:

public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
  } else {
    result = otherValue != null && thisValue.equals(otherValue); // questionable null check
  }
  return result;
}

这里的额外检查other != null仅在equals()方法不能按照其契约要求检查null时才有必要。

我没有与同事就让有bug的代码留在代码库中是否明智进行毫无结果的争论，而是简单地在代码中放入了两个断言。这些断言会让我知道，在开发阶段，如果我们的一个类不能正确地实现equals()，所以我可以修复它:

public static boolean compare(final Object thisValue, final Object otherValue) {
  boolean result;
  if (thisValue == null) {
    result = otherValue == null;
    assert otherValue == null || otherValue.equals(null) == false;
  } else {
    result = otherValue != null && thisValue.equals(otherValue);
    assert thisValue.equals(null) == false;
  }
  return result;
}

需要记住的要点如下:

Assertions are development-phase tools only. The point of an assertion is to let you know if there's a bug, not just in your code, but in your code base. (The assertions here will actually flag bugs in other classes.) Even if my colleague was confident that our classes were properly written, the assertions here would still be useful. New classes will be added that might fail to test for null, and this method can flag those bugs for us. In development, you should always turn assertions on, even if the code you've written doesn't use assertions. My IDE is set to always do this by default for any new executable. The assertions don't change the behavior of the code in production, so my colleague is happy that the null check is there, and that this method will execute properly even if the equals() method is buggy. I'm happy because I will catch any buggy equals() method in development.

此外，您应该通过放入一个将失败的临时断言来测试断言策略，这样您就可以确定通过日志文件或输出流中的堆栈跟踪来通知您。

下面是最常见的用例。假设你正在打开一个枚举值:

switch (fruit) {
  case apple:
    // do something
    break;
  case pear:
    // do something
    break;
  case banana:
    // do something
    break;
}

只要你处理每一个案子，就没问题。但是有一天，有人会把fig添加到你的枚举中，而忘记把它添加到你的switch语句中。这将产生一个难以捕捉的错误，因为直到您离开switch语句后才会感受到其影响。但是如果你像这样写开关，你可以立即捕获它:

switch (fruit) {
  case apple:
    // do something
    break;
  case pear:
    // do something
    break;
  case banana:
    // do something
    break;
  default:
    assert false : "Missing enum value: " + fruit;
}

断言用于检查后置条件和“永不失败”的前提条件。正确的代码应该永远不会使断言失败;当它们触发时，它们应该指出一个错误(希望是在接近问题的实际位置的地方)。

断言的一个例子可能是检查一组特定的方法是否以正确的顺序被调用(例如，在迭代器中hasNext()在next()之前被调用)。

一个真实的例子，来自一个stack类(来自Java文章中的断言)

public int pop() {
   // precondition
   assert !isEmpty() : "Stack is empty";
   return stack[--num];
}

断言是可以被关闭的检查。它们很少被使用。为什么?

它们不能用于检查公共方法参数，因为您无法控制它们。 它们不应该用于简单的检查，如result != null，因为这样的检查非常快，几乎没有什么可以保存。

那么，还剩下什么呢?昂贵的条件检查是真实的。像rb树这样的数据结构的不变量就是一个很好的例子。实际上，在JDK8的ConcurrentHashMap中，对于TreeNodes有一些这样有意义的断言。

您确实不希望在生产环境中启用它们，因为它们很容易控制运行时间。 您可能希望在测试期间打开或关闭它们。 在处理代码时一定要打开它们。

有时候，支票不是很贵，但与此同时，你很确定，它会通过。在我的代码中，有例如，

assert Sets.newHashSet(userIds).size() == userIds.size();

我很确定我刚刚创建的列表有独特的元素，但我想记录并再次检查它。