番石榴前提条件checkNull，checkArgument [英] Guava preconditions checkNull, checkArgument

问题描述

我想检查基类的前置条件，以便我知道子类型总是使用有效的构造函数参数。

I want to check preconditions on a base class so that I know subtypes will always use constructor arguments that are valid.

我们以一个构造函数为例：

Let's take as an example a constructor that:

1. 需要2个或更多参数


2. 获取不同类型的参数


3. 对于一个参数，它执行多次检查（例如String不为空且不为空）

1. takes 2 or more parameters
2. takes parameters of different types
3. for one parameter, it performs multiple checks (e.g. String is not null and not empty)

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

How would one best use the Guava preconditions approach in that case?

在这样的模拟示例中:(这是人为的！）

In a mock example like this: (this is contrived!)

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

I end up calling super before checking the arguments because a call to super needs to be the first line of the method and, although I could do super(checkNoNull(errorMessage)), I cannot do the same wrapping using checkArgument because that returns void. So the dilemma is:

• 我在哪里对所有参数进行检查？我不想仅为此创建一个构建器


• 如何在虚构的 checkStringNotNullAndNotEmpty（）中分组检查


• 我是否应该考虑与匹配器框架集成？ （hamcrest，fest断言......）

• Where do I put the checks on all arguments? I don't want to create a Builder just for that
• How do I "group" checks as in a fictitious checkStringNotNullAndNotEmpty()
• Should I rather think about integration with matchers frameworks? (hamcrest, fest assertions...)

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

I use the odd-looking ErrorMessage.MethodArgument.CANNOT_BE_NULL_CHECK because the default throw does not include an error message so from the testing side I cannot recognise this as an argument validation failure rather than a "any" NPE?

我做错了吗？

推荐答案

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

This should have been a comment, but it's too long.

• 在测试无害之前调用 super ，前提是超级ctor不执行任何操作它不应该这样做。


• 可以通过静态构建器方法阻止它，不需要构建器。但这不值得。


• 我怀疑分组测试通常有用;如果是的话，那么就已经有了这样的方法。但如果你需要一件这样一件具体的东西超过两次，那就写下你自己的;如果它经常出现，请将其作为RFE报告给Guava团队。


• 我很确定，匹配器在这里是一种矫枉过正，因为你只是在创建一个例外，即使用的东西很少（我希望）。由于您的测试仅限运行时，无法真正帮助捕获错误。如果你可以静态地确保正确构造的异常，那将是不错的，但在纯java中是不可能的。

• Calling super before the test is harmless provided that the super ctor doesn't do things which it shouldn't do anyway.
• It could be prevented via a static builder method, you need no Builder. But it's not worth it.
• I doubt that grouping tests is generally useful; if it was, then there would be a such method already. But if you need one such a concrete thing more than twice, then write your own; if it comes often, report it to the Guava team as an RFE.
• I'm pretty sure, matchers are an overkill here as you're just creating an exception, i.e., something used only rarely (I hope). As your test is runtime only, it can't really help to catch errors. It would be nice, if you could statically ensure a "properly" constructed exception, but it's impossible in pure java.

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

More important: The exceptions you're throwing are probably inferior to the ones you'd get without all the checks. Imagine the user provides a cause and no message. That's bad, you think, but you replace it with an NPE lacking any cause. That's worse.

查看Guava的 Preconditions.format （包私有）。他们可以先检查正确的参数数量，但事实并非如此。您可以提供太少或太多，这是一个错误，但忽略它是处理它的最佳方式。

Look at Guava's Preconditions.format (package private). They could check the correct number of arguments first, but they do not. You can provide too few or too many, which is an error, but ignoring it is the best way to handle it.

这篇关于番石榴前提条件checkNull，checkArgument的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！