检查构造函数/方法参数

Question

我通常通过Guava的Precondition方法检查几乎所有的构造函数和公共方法参数。 私有方法参数通常带有断言。 但是，现在我正在考虑替换“内部”前置条件检查，即检查构造函数/工厂方法/一般方法（不属于公共API /应用程序API）...使用断言，您如何看待？ 也许这种方式有点快，因为我有很多支票;-)

编辑：我的意思是公共构造函数和工厂，它们不应该是公共API的一部分，只是在内部使用，例如：

/**
 * Constructor with both, complete and modifying page.
 * 
 * @param complete
 *          to be used as a base for this container
 * @param modifying
 *          to be used as a base for this container
 */
public NodePageContainer(final @Nonnull NodePage complete,
    final @Nonnull NodePage modifying) {
  assert complete != null;
  assert modifying != null;
  mComplete = complete;
  mModified = modifying;
}

在我有mComplete = checkNotNull(complete); ...但它只是从另一个包中的类调用，甚至不应该是公共API的一部分。 如果Java允许降低此类的可见性，那将会很棒;-)

Answer 1

断言和先决条件不是一回事。

断言检查不变量是否受到尊重：它检查您自己的算法是否按预期工作。 例如，随机生成器生成的数字始终为正数。 一旦检查一切正常并且没有断言失败，就可以取消激活它们。

Guava前置条件检查调用者是否未传递无效参数或不调用不应调用的方法。 例如，作为参数传递给nextInt()方法的限制大于0，或者在随机生成器启动后不调用setSeed() 。

如果您的目标是强制API的调用者尊重其合同，那么我将使用Guava前置条件，而不是断言。

Answer 2

根据Effective Java您应该对API公开的方法使用检查（ Preconditions ），对非API方法使用断言。 这意味着任何非private或package private方法/构造函数都应该使用检查。 WRT， private和private package private ，使用断言更有效，建议在部署早期启用断言以协助调试，然后选择在生产周期的后期禁用它们，因为信心增加，性能成为问题。

Answer 3

我同意你的推理，但我会在你的例子中使用Precondition 。 从外面可以看到构造函数，所以你可以打赌有人会在某一天调用它。 测试是如此便宜，所以它不值得麻烦。

实际上，这是我的辅助标准：我主要根据API /非API原则做出决定，但有时会对非常便宜或非常昂贵的检查做出例外处理（也取决于上下文和因缺少检查而可能造成的伤害的数量）。