我想检查基类的先决条件，以便我知道子类型将始终使用有效的构造函数参数。
让我们以一个构造函数为例：
- 需要 2 个或更多参数
- 接受不同类型的参数
- 对于一个参数，它执行多次检查（例如 String 不为 nulland不是空的）
在这种情况下，如何最好地使用 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，节断言......）
我使用看起来很奇怪的 Error Message.Method Argument.CANNOT _BE_NULL_CHECK 因为默认值throw不包含错误消息，因此从测试方面我无法将其识别为参数验证失败而不是“任何”NPE？
我这一切都做错了吗？
这应该是一个评论，但它太长了。
- Calling
super在测试之前是无害的，前提是超级 ctor 不做以下事情无论如何都不应该这样做.
- 可以通过静态构建器方法来防止它，您不需要构建器。但这不值得。
- 我怀疑分组测试是一般来说有用;如果是的话，那么早就有这样的方法了。但如果你需要这样一个具体的东西超过两次，那就写你自己的；如果经常出现，请以 RFE 的形式向 Guava 团队报告。
- 我很确定，匹配器在这里是一种矫枉过正，因为您只是创建一个例外，即很少使用的东西（我希望）。由于您的测试仅是运行时，因此实在帮不上忙捕获错误。如果您能够静态地确保“正确”构造异常，那就太好了，但在纯 java 中这是不可能的。
更重要的是：您抛出的异常可能不如没有所有检查时得到的异常。想象一下用户提供了一个原因但没有任何消息。你认为这很糟糕，但你却用没有任何理由的 NPE 替换了它。那就更糟了。
看看番石榴的Preconditions.format（包私有）。他们可以先检查参数的数量是否正确，但他们没有。你可以提供太少或太多，这是一个错误，但忽略它是处理它的最好方法。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
