当前位置：文江博客话题详情

我什么时候应该使用 Apache Commons？ Validate.isTrue，什么时候我应该使用“assert”？关键词？

发布于 2024-10-18 10:06:38 字数 70 浏览 4 评论 0原文

什么时候应该使用 Apache Commons 的 Validate.isTrue，什么时候应该只使用“assert”关键字？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

日久见人心 2024-10-25 10:06:38

Validate.isTrue 和“assert”具有完全不同的目的。

断言
Java 的断言语句通常用于记录（通过手段
断言）在什么情况下可以调用方法，以及
他们的来电者随后可以期望得到什么。断言可以
可以选择在运行时进行检查，从而导致断言错误
如果不成立则例外。

就契约设计而言，断言可用于定义
前置条件和后置条件以及类不变量。如果在运行时
这些被检测到不成立，这指向设计或实现
系统中的问题。

验证.isTrue
org.apache.commons.lang.Validate 是不同的。它提供了一个简单的集合
类似于 JUnit 的方法，用于检查条件并抛出异常
如果条件不成立，则显示“IllegalArgumentException”。

它通常在公共 API 应容忍不良行为时使用
输入。在这种情况下，它的合同可以承诺抛出一个
输入错误时出现 IllegalArgumentException。 Apache Validate 优惠
实现这一点的便捷简写。

既然抛出了IllegalArgumentException，那就没有意义了
使用 Apache 的 Validate 检查后置条件或不变量。
同样，使用“assert”进行用户输入验证也是不正确的，
因为可以在运行时禁用断言检查。

同时使用
不过，可以同时使用两者，尽管
出于不同的目的。在这种情况下，合同应明确
要求在某些类型上引发 IllegalArgumentException
输入的。然后通过 Apache Validate 实现。
然后也简单地断言不变量和后置条件
尽可能附加的先决条件（例如影响
物体的状态）。例如：

public int m(int n) {
  // the class invariant should hold upon entry;
  assert this.invariant() : "The invariant should hold.";

  // a precondition in terms of design-by-contract
  assert this.isInitialized() : "m can only be invoked after initialization.";

  // Implement a tolerant contract ensuring reasonable response upon n <= 0:
  // simply raise an illegal argument exception.
  Validate.isTrue(n > 0, "n should be positive");

  // the actual computation.
  int result = complexMathUnderTrickyCircumstances(n);

  // the postcondition.
  assert result > 0 : "m's result is always greater than 0.";
  assert this.processingDone() : "processingDone state entered after m.";
  assert this.invariant() : "Luckily the invariant still holds as well.";

  return result;
}

更多信息：

Bertrand Meyer，“应用合同设计”，IEEE 计算机，1992 (pdf< /a>)
约苏亚·布洛赫。 Effective Java，第二版，第 38 项。检查参数的有效性。 (Google 图书)

Validate.isTrue and 'assert' serve completely different purposes.

assert
Java's assert statements are typically used for documenting (by means
of assertions) under what circumstances methods can be invoked, and
what their callers can expect to be true afterward. The assertions can
optionally be checked at run time, resulting in an AssertionError
exception if they don't hold.

In terms of design-by-contract, assertions can be used to define
pre- and postconditions as well as class invariants. If at run time
these are detected not to hold, this points to a design or implementation
problem in the system.

Validate.isTrue
org.apache.commons.lang.Validate is different. It offers a simple set
of JUnit-like methods which check a condition, and throw an
"IllegalArgumentException" if the condition does not hold.

It is typically used when a public API should be tolerant against bad
input. In that case, its contract can promise to throw an
IllegalArgumentException upon erroneous input. Apache Validate offers
a convenient shorthand for implementing this.

Since an IllegalArgumentException is thrown, it does not make sense
to use Apache's Validate to check postconditions or invariants.
Likewise, it is incorrect to use 'assert' for user input validation,
since assertion checking can be disabled at run time.

Using both
It is possible, though, to use both at the same time, albeit
for different purposes. In this case, the contract should explicitly
require IllegalArgumentException to be raised upon certain types
of input. This is then implemented via Apache Validate.
Invariants and postconditions are then simply asserted, as well
as possible additional preconditions (for example affecting the
state of the object). For example:

public int m(int n) {
  // the class invariant should hold upon entry;
  assert this.invariant() : "The invariant should hold.";

  // a precondition in terms of design-by-contract
  assert this.isInitialized() : "m can only be invoked after initialization.";

  // Implement a tolerant contract ensuring reasonable response upon n <= 0:
  // simply raise an illegal argument exception.
  Validate.isTrue(n > 0, "n should be positive");

  // the actual computation.
  int result = complexMathUnderTrickyCircumstances(n);

  // the postcondition.
  assert result > 0 : "m's result is always greater than 0.";
  assert this.processingDone() : "processingDone state entered after m.";
  assert this.invariant() : "Luckily the invariant still holds as well.";

  return result;
}

More information:

Bertrand Meyer, "Applying Design by Contract", IEEE Computer, 1992 (pdf)
Johsua Bloch. Effective Java, 2nd ed., Item 38. Check parameters for validity. (google books)

回复收藏 0 原文