使用断言的一些（反）模式（Java 和其他）

Question

最后，我有一个问题想在 Stack Overflow 上问！ :-)

主要目标是 Java，但我相信它主要与语言无关：如果您没有本机断言，您始终可以模拟它。

我在一家销售用 Java 编写的软件套件的公司工作。 代码很旧，至少可以追溯到 Java 1.3，并且在某些地方，它显示...这是一个很大的代码库，大约有 200 万行，所以我们无法一次重构它。
最近，我们将最新版本从 Java 1.4 语法和 JVM 切换到 Java 1.6，保守地使用了一些新功能，例如 assert （我们以前使用 DEBUG.ASSERT 宏 - 我知道 assert 已经在 1.4 中引入了，但我们之前没有使用过），泛型（仅类型化集合），foreach 循环，枚举等。

我对断言的使用还是有点陌生​​，虽然我已经阅读过关于该主题的几篇文章。 然而，我看到的一些用法让我感到困惑，损害了我的常识...... ^_^ 所以我想我应该问一些问题，看看我想要纠正的东西是否正确，或者它是否违背了惯例。 我很啰嗦，所以我加粗问题，以供那些喜欢浏览内容的人使用。

作为参考，我在 SO 中搜索了 assert java 并发现了一些有趣的线程，但显然没有完全相同的重复。

• 如何在java中避免“！= null”语句？ 和 多少 null 检查足够了吗？ 非常相关，因为我们只是检查变量是否为空，因此很多断言。 在我们的代码中的某些地方，存在 null 对象的用法（例如返回 new String[0]），但并非总是如此。 我们必须忍受这一点，至少是为了维护遗留代码。
• Java 断言未充分使用 中也有一些很好的答案。
• 哦，SO 有理由指出 我什么时候应该使用 Debug.Assert()？ 问题也相关（减少重复的好功能！）。

首先，主要问题，引发了我今天的问题：（

SubDocument aSubDoc = documents.GetAt( i );
assert( aSubDoc != null );
if ( aSubDoc.GetType() == GIS_DOC )
{
   continue;
}
assert( aSubDoc.GetDoc() != null );
ContentsInfo ci = (ContentsInfo) aSubDoc.GetDoc();

是的，我们使用 MS 的 C/C++ 风格/代码约定。我什至喜欢它（来自相同的背景）！所以起诉我们。）
首先，assert() 形式来自 DEBUG.ASSERT() 调用的转换。 我不喜欢额外的括号，因为断言是一种语言构造，而不是（这里不再是）函数调用。 我也不喜欢 return (foo); :-)
接下来，断言在这里不测试不变量，而是用作防止错误值的防范措施。 但据我了解，它们在这里毫无用处：断言将抛出异常，甚至不会用伴随字符串记录，并且只有在启用断言的情况下。 因此，如果我们有 -ea 选项，我们只会抛出一个断言，而不是常规的 NullPointerException 断言。 这看起来并不是一个最重要的优势，因为无论如何我们都会在最高级别捕获未经检查的异常。
我是否正确地假设我们可以摆脱它们并接受它（即让Java引发这种未检查的异常）？（或者，当然，如果可能的话，测试空值，这是在其他中完成的）的地方）。

旁注：如果我必须在上面的代码片段中断言，我会针对 ci 值而不是针对 getter 这样做：即使大多数 getter 都经过优化/内联，我们也不能确定，所以我们应该避免调用它两次。

有人告诉我们，在最后一个引用的线程中，公共方法应该使用针对参数值的测试（公共 API 的使用），而私有方法应该依赖于断言。 好建议。
现在，这两种方法都必须检查另一个数据源：外部输入。 IE。 例如，来自用户、数据库、某些文件或网络的数据。
在我们的代码中，我看到针对这些值的断言。 我总是将这些更改为实际测试，因此即使禁用断言，它们也会起作用：这些不是不变的，必须正确处理。
我只看到一个可能的例外，其中输入被假定为常量，例如数据库表填充了关系中使用的常量：如果该表发生更改但相应的代码未更新，程序将中断。
你看到其他异常了吗？

我看到的另一个相对频繁的使用，看起来不错：在默认的开关中，或者在一系列 else if 测试所有的末尾可能的值（这些情况可以追溯到我们使用枚举之前！），通常会出现一个 assert false ：“Unexpected value for stuff:” + stuff;
对我来说看起来是合法的（这些情况不应该在生产中发生），你觉得怎么样？（除了“不切换，使用面向对象”的建议，这些建议与这里无关）。

最后，我错过了还有其他有用的用例或烦人的陷阱吗？ （大概！）

Answer 1

第一条规则是避免断言中的副作用。 换句话说，断言关闭时代码的行为应该与断言打开且不会失败时的行为相同（显然失败的断言将改变行为，因为它们会引发错误）。

第二条规则是不要使用断言进行必要的检查。 它们可以被关闭（或者，更准确地说，不能打开）。 对于非私有方法的参数检查，请使用 IllegalArgumentException。

断言是可执行的假设。 我使用断言来表达我对程序当前状态的信念。 例如，诸如“我假设此处 n 为正”或“我假设列表此处只有一个元素”之类的内容。

Answer 2

我使用assert，不仅用于参数验证，还用于验证线程。
每次我执行 swing 时，我都会在几乎每个方法中编写断言来标记“我应该只在工作线程/AWTThread 中执行”。 （我认为 Sun 应该为我们做这件事。）由于 Swing 线程模型，如果您从非 UI 线程访问 swing api，它可能不会失败（并且随机失败）。 如果不断言，要找出所有这些问题是相当困难的。

我能想到的另一个例子是检查 JAR 附带的资源。 你可以有英语例外，而不是 NPE。

---

编辑：
另一个例子; 对象锁定检查。 如果我知道我将使用嵌套同步块，或者当我要修复死锁时，我会使用 Thread.holdLock(Object) 确保我不会以相反的顺序获得锁。

---

编辑（2）：如果您非常确定某些代码块永远不会到达，您可以编写

throw new AssertionError("You dead");

而不是

assert false:"I am lucky";

例如，如果您在可变对象上覆盖“equals（Object）”，则如果您相信的话，请使用 AssertionError 覆盖 hashCode()永远不会成为关键。 一些书籍中建议采用这种做法。 我不会损害性能（因为它永远不应该达到）。

Answer 3

您已经谈到了我认为一般应该避免断言的许多原因。 除非您使用的代码库中断言的使用有非常严格的指导方针，否则您很快就会陷入无法关闭断言的情况，在这种情况下，您可能只使用正常的逻辑测试。

所以，我的建议是跳过断言。 不要坚持额外的空指针检查，语言会为你做这件事。 但是，如果指针可能暂时不会被取消引用，则预先进行空检查是一个好主意。 另外，始终对于“永远”不应该发生的情况（最后的 if 分支或默认 switch 情况）使用真正的异常，不要使用“assert false”。 如果你使用断言，有人可能会关闭它，如果这种情况真的发生，事情会变得非常混乱。

Answer 4

我建议检查公共 (API) 方法中的参数，如果参数无效，则抛出 IllegalArgumentException。 这里没有断言，因为 API 用户需要获得正确的错误（消息）。

断言应该在非公共方法中使用来检查后置条件和可能的前置条件。 例如：

List returnListOfSize(int size) {
    // complex list creation
    assert list.size == size;
}

通常使用巧妙的错误处理策略可以规避断言。