3

自从我与 JVM 进行单人战斗以来已经有很多年了，我想我忘记了一些事情。

得到了一些有大量断言的代码，没有自定义消息，只是assert some_condition; 我已经验证过的普通代码-ea正在传递给 VM，并在启动时以编程方式仔细检查了断言是否启用。

调用链更高的是如下代码：

try {
    start_the_deeply_nested_stuff();
}
catch (Throwable e) {
    do stuff with e.getMessage()
}

AssertionError的文档说它是 Throwable 的后裔，并且始终使用断言的表达式作为 ctor 参数构造它（在转换为字符串之后）。我觉得我应该能够在这里调用 getMessage() 并得到一些有用的东西，比如"assertion failed on file X line Y because your code shits"。

相反，getMessage() 返回 null。我能够弄清楚断言正在被触发的唯一方法是循环e.getStackTrace()并跟踪行号。

getMessage 怎么了？AssertionError 是否总是应该包含有关触发它的条件的内容？

4

1 回答 1

1

AssertionError 是否总是应该包含有关触发它的条件的内容？

显然不是基于文档。

表达方式

assert args != null;

将抛出没有详细消息的 AssertionError（如果 args 为空）

assert args != null : "Arguments must not be null";

将抛出带有详细消息的 AssertionErrorArguments must not be null

我同情。如果编译器足够聪明，可以接受这样的表达式，那就太酷了

assert args != null;

并抛出带有消息“args！= null”的 AssertionError 但我想这不是它的工作原理。

我想您可以编写一个脚本来遍历所有旧代码，检测断言表达式并将它们替换为以下内容：

assert <expression> : "<text of expression>";

如

assert args != null : "args != null";
于 2012-11-20T17:35:57.650 回答