番石榴前提条件checkNull，checkArgument

 

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

我们以构造函数为例说明：

  • 需要2个或更多参数
  • 采用不同类型的参数
  • 对于一个参数，它执行多重检查（例如，字符串不为空且不为空）

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

    在这样一个模拟例子中:(这是人为的！） 

    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 。 所以困境是：

  • 我在哪里将检查放在所有参数上？ 我不想为此创建一个Builder
  • 我如何“组”检查虚构的checkStringNotNullAndNotEmpty()
  • 我应该考虑与matchers框架进行整合吗？ （hamcrest，fest断言......）

    • 我使用了奇怪的ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK，因为默认的throw没有包含错误消息，所以从测试端我不能认识到这是一个参数验证失败而不是“任何”NPE？

    我做错了什么吗？

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

  • 如果超级玩家不做任何不该做的事情，那么在测试之前打电话super无害。
  • 它可以通过静态构建器方法来防止，你不需要Builder。 但这不值得。
  • 我怀疑分组测试通常是有用的; 如果是的话，那么就会有这样的方法。 但是如果你需要两次以上的具体事物，那么写下你自己的; 如果经常发生，请以RFE的形式向Guava团队报告。
  • 我很确定，匹配器在这里是一种矫枉过正的情况，因为你只是在创建一个异常，也就是很少使用的东西（我希望）。 由于您的测试仅限于运行时，因此无法真正帮助您发现错误。 如果你可以静态地确保一个“正确”构造的异常，但是在纯Java中是不可能的，那将是很好的。

    • 更重要的是：你抛出的例外情况可能不如没有进行所有检查的情况。 想象一下，用户提供了一个原因，没有消息。 你认为这很糟糕，但是你用一个缺乏任何原因的NPE取而代之。 这更糟糕。

    看看Guava的Preconditions.format （私人包裹）。 他们可以首先检查正确的参数数量，但他们不会。 你可以提供太少或太多，这是一个错误，但忽略它是处理它的最好方法。

    链接地址: http://www.djcxy.com/p/76229.html

    上一篇: Guava preconditions checkNull, checkArgument

    下一篇: Automated IllegalArgumentException message?