java - Guava 的前提条件checkNull，checkArgument

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

让我们以一个构造器为例：


接受2个或更多参数
接受不同类型的参数
对于一个参数，它会执行多项检查（例如String不为null并且不为空）


在这种情况下，如何最好地使用番石榴前提条件方法？

在这样的模拟示例中：（这是人为的！）

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断言...）


我使用外观怪异的ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK，因为默认throw不包含错误消息，因此从测试方面，我无法将其识别为参数验证失败，而不是“任何” NPE？

我做错了吗？

最佳答案

这本来应该是一个评论，但是太长了。


在测试之前调用super是无害的，只要超级控制器不执行它不应该执行的操作即可。
可以通过静态构建器方法来防止它，您不需要构建器。但这不值得。
我怀疑分组测试通常很有用；如果是这样，那么已经有这样的方法了。但是，如果您需要两次以上这样的具体事情，请自己编写；如果经常出现，请将其作为RFE报告给番石榴团队。
我敢肯定，匹配者在这里是一个过大的杀手，因为您只是在创建一个例外，即，很少使用的东西（我希望）。由于您的测试仅是运行时，因此并不能真正帮助您捕获错误。如果可以静态地确保“正确地”构造的异常，那将很好，但是在纯Java中这是不可能的。


更重要的是：您抛出的异常可能不如没有所有检查的异常。假设用户提供了原因，但没有消息。您认为这很糟糕，但是您可以使用没有任何原因的NPE替换它。更糟

查看番石榴的Preconditions.format（私有软件包）。他们可以先检查正确数量的参数，但不能。您可以提供太少或太多，这是一个错误，但忽略它是处理它的最佳方法。

关于java - Guava 的前提条件checkNull，checkArgument，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/12804882/