Java-Guava前提条件checkNull,checkArgument

2019-10-11 16:01:43 阅读：172 来源： 互联网

标签：java guava

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

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

>接受2个或更多参数
>接受不同类型的参数
>对于一个参数,它将执行多项检查(例如,字符串不为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,因为默认抛出不包含错误消息,因此从测试方面,我无法将其识别为参数验证失败,而不是“任何” NPE？

我做错了吗？

解决方法:

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

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

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

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

标签：java,guava
来源： https://codeday.me/bug/20191011/1893844.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

Java-Guava前提条件checkNull,checkArgument