Question

自从我与JVM进行单一战斗以来已经很久了，我想我已经忘记了什么。

有一些代码有大量的断言，没有自定义消息，只有普通的assert some_condition;我已经验证-ea正在传递给VM，并在启动时以编程方式进行双重检查断言是在面部启用。

调用链越高，代码如下：

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

AssertionError的文档说它是Throwable的后代，并且它总是用断言的表达式构造为ctor参数（在转换为字符串之后）。我觉得我应该能够在这里调用getMessage（）并获得一些有用的东西，比如“文件X行Y上的断言失败，因为你的代码糟透了”。

相反，getMessage（）返回null。我能够找出断言被触发的唯一方法是循环e.getStackTrace()并跟踪行号。

getMessage有什么用？是不是AssertionError总是应该包含一些关于触发它的条件？

Answer 1

是不是AssertionError总是应该包含一些关于触发它的条件？

显然不是 - 基于docs。

表达式

assert args != null;

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

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

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

的AssertionError

我很同情。如果编译器足够智能，可以采用像

这样的表达式，那将是非常酷的

assert args != null;

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

我想你可以编写一个脚本来浏览所有旧代码，检测断言表达式并用以下内容替换它们：

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

，例如

assert args != null : "args != null";