小编典典

番石榴的前提条件checkNull,checkArgument

java

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

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

  1. 接受2个或更多参数
  2. 接受不同类型的参数
  3. 对于一个参数,它执行多次检查(例如,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在检查参数之前先进行了调用,因为对to的调用必须super是方法的第一行,尽管可以这样做super(checkNoNull(errorMessage)),但是我不能使用相同的包装方法,checkArgument因为那会返回void。因此,难题是:

  • 我应该在哪里检查所有参数?我不想为此创建一个生成器
  • 我如何像在虚拟机中一样“分组”检查 checkStringNotNullAndNotEmpty()
  • 我是否应该考虑与匹配器框架集成?(hamcrest,fest断言…)

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

我做错了吗?


阅读 255

收藏
2020-11-26

共1个答案

小编典典

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

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

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

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

2020-11-26