java - Guava 先决条件 checkNull、checkArgument

Question

我想检查基类的前提条件，以便我知道子类型将始终使用有效的构造函数参数。

让我们以一个构造函数为例:

1. 接受 2 个或更多参数
2. 接受不同类型的参数
3. 对于一个参数，它执行多项检查(例如，字符串不为空并且不为空)

在这种情况下，如何最好地使用 Guava 先决条件方法？

在这样的模拟示例中:(这是人为的!)

protected AbstractException(String errorMessage, Throwable errorCause) {
  super(errorMessage, errorCause);
  checkNotNull(errorMessage,
      ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK, "errorMessage");
  checkArgument(!errorMessage.isEmpty(),
      ErrorMessage.MethodArgument.CANNOT_BE_EMPTY_STRING_CHECK,
      "errorMessage");
  checkNotNull(errorCause, ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK,
      "errorCause");
}

我最终在检查参数之前调用了 super，因为对 super 的调用需要成为该方法的第一行，尽管我可以调用 super (checkNoNull(errorMessage))，我无法使用 checkArgument 进行相同的包装，因为它会返回 void。所以困境是:

• 我在哪里检查所有参数？我不想为此创建构建器
• 如何像在虚构的 checkStringNotNullAndNotEmpty()
中那样“分组”检查
• 我应该考虑与匹配器框架集成吗？ (hamcrest, fest assertions...)

我使用看起来很奇怪的 ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK 因为默认的 throw 不包含错误消息所以从测试方面我无法将其识别为参数验证失败而不是“任何” “NPE？

我做错了吗？

Answer 1

这应该是一条评论，但它太长了。

• 在测试前调用 super 是无害的，前提是 super ctor 不做无论如何都不应该做的事情。
• 它可以通过静态生成器方法来阻止，你不需要生成器。但这不值得。
• 我怀疑分组测试通常是否有用；如果是的话，那么早就有这样的方法了。但是，如果您多次需要这样一个具体的东西，那就自己写吧；如果经常出现，请将其作为 RFE 报告给 Guava 团队。
• 我很确定，匹配器在这里有点矫枉过正，因为您只是在创建一个异常(exception)，即很少使用的东西(我希望如此)。由于您的测试只是运行时，它不能真正帮助捕获错误。如果您可以静态地确保“正确”构造异常，那就太好了，但这在纯 Java 中是不可能的。

更重要的是:您抛出的异常可能不如您在没有进行所有检查的情况下获得的异常。想象一下，用户提供了原因但没有消息。你认为这很糟糕，但你用没有任何原因的 NPE 代替了它。那更糟。

看Guava的Preconditions.format(package private)。他们可以先检查参数的正确数量，但他们没有。您可以提供太少或太多，这是一个错误，但忽略它是最好的处理方式。