java - 提供给 Google Guava 的 Preconditions.* 方法的正确错误消息是什么？

Question

例如，当使用Preconditions.checkArgument时，错误消息应该反映相关检查的通过情况还是失败情况？

import static com.google.common.base.Preconditions.*;

void doStuff(int a, int b) {
  checkArgument(a == b, "a == b");
  // OR
  checkArgument(a == b, "a != b");
}

Answer 1

Answer 2

该文档提供了示例，这些示例使用单词而不是符号非常清楚：

checkArgument(count > 0, "must be positive: %s", count);

鉴于这些基本上只是日志（或调试会话）中的异常消息，做任何你认为能让任何人看问题的人或阅读代码以理解前提条件的人最清楚的事情。

例如，您可以将上面的内容重写为：

checkArgument(count > 0, "count must be positive; was actually %s", count);

Answer 3

就个人而言，对于这样的事情，我想我会写

checkArgument(a == b, "a (%s) must equal b (%s)", a, b);

Answer 4

通常（大多数时候）您可以只使用不带错误消息参数的 checkArgument() 方法，也就是说，根本不提供错误消息。

要制作好的错误消息，需要了解谁将阅读该消息。它不是最终用户；如果前提条件失败，则最有可能指向代码中的错误。该文本可以解释失败的前提条件，但在大多数情况下，它对最终用户没有用，它应该是对程序员的提示。大多数时候，如果没有堆栈跟踪和源代码，消息本身也毫无意义。事实上，在大多数情况下，堆栈跟踪和源代码正是程序员修复错误所需要的，错误消息无济于事。如果前提条件不明显，则在其旁边添加注释是记录它的完美方式。

在没有人真正关心文本的情况下始终提供错误消息的需要导致程序员制作无用、明显和无用的消息，这只会使代码的可读性降低。

在某些情况下，错误消息可能很有用，例如消息可以包含变量的实际值，但根据我们的经验，这种情况并不常见，在这些情况下，您可以使用该消息。

类似的论点也适用于 JUnit 中的断言方法；总是提供错误消息不是一个好主意。

此外，当您在库而不是最终用户的应用程序中使用前置条件时，情况可能会有所不同，因为您不知道如何使用您的代码。

Answer 5