Question

It’s been ages since I engaged in single combat with a JVM, and I think I’ve forgotten something.

Got some code that has a ton of assertions, none with custom messages, just plain old assert some_condition; I’ve verified that -ea is being passed to the VM, and double-checked programmatically at startup that assertions are in face enabled.

Higher up the call chain is code that looks like this:

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

The docs for AssertionError say that it’s descended from Throwable, and that it’s always constructed with the asserted expression as the ctor argument (after being converted to a string). I feel like I should be able to call getMessage() here and get something useful back, like “assertion failed on file X line Y because your code sucks”.

Instead, getMessage() returns null. The only way I’ve been able to figure out that an assertion is being triggered at all is by looping over e.getStackTrace() and tracking down line numbers.

What’s up with getMessage? Isn’t AssertionError always supposed to include something about the condition which triggered it?

Answer 1

Isn’t AssertionError always supposed to include something about the condition which triggered it?

Apparently not – based on the docs.

The expression

assert args != null;

will throw an AssertionError with no detail message (if args is null)

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

will throw an AssertionError with the detail message Arguments must not be null

I sympathize. It would be really cool if the compiler was smart enough to take an expression like

assert args != null;

and throw an AssertionError with the message “args != null” but I guess that’s not how it works.

I suppose you could write a script to go through all your old code, detect assert expressions and replace them with something like:

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

such as

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