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和package private，使用断言更有效，建议在部署早期启用断言以协助调试，然后选择在生产周期的后期禁用它们，因为信心增长并且性能成为问题。

Answer 3

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

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

检查构造函数/方法参数

3 个答案: