Assertions being built into Java is nice and they’ve been around since version 1.4. They predate type parameters! I have never seen them being used and the reason always seems to be that because you can’t count on them being turned on because they’re off by default.
The only theoretical use I can think of it for “executable comments”, as in something like the example below, but they’re annoying as the IDE will usually complain that it is always true (with no way to specifically disable warning for always true assertions, only always true conditions in general).
if (condition) {
// Very long block of code
} else {
assert !condition; // Primarily a reminder for when the if condition is not easily seen
}
Here it doesn’t matter if the assertion is executed or not because it is just a reminder. The idea being that code sticks out more than a comment.
It always felt like they were a relic from an older version of Java. I have used it once during a university lecture and that was it. I think they are also not so useful if you have good unit tests and have well-structured code. In most cases where they would be useful, it is probably still safer to use actual if statements, even if that adds more boilerplate to the code.
You are not wrong that they are in a way “executable comments”. Just like comments they are intended only for development/debugging and can’t (shouldn’t) have any influence on production code.
For example, in your sample code the
if
is unnecessary, becausecondition
can’t be (should not be)true
. If it were, it would be a bug. Instead it should be written as:assert !condition; // Very long block of code
If the condition can ever be
true
then you shouldn’t be usingassert
.Sorry, the example wasn’t clear, I meant to have a normal if statement for normal things and then assert that the condition that you just checked in the if is false in the else before doing what you’d normally do in the else block. Something like this.
if (isEven) { log.info("it's even"); } else { assert !isEven; log.info("it's odd"); }
Again, not a great example because the code is short enough to clearly see the entire thing, but it better illustrates what I meant.
To be honest that doesn’t change anything about what I said. The assertion condition must never be
true
at runtime. If it ever can be, then it’s a wrong use ofassert
.In that example it can’t be true in the else block (assuming it is a local variable).
I think the idea was that you could run extra checks by in a QA environment without bearing the runtime cost of all the
if (QA)
tests in your production code.No, I’ve never used it. Our company style guide discourages it because even in QA it would be too easy for some config to get lost/forgotten and give unexpected behavior. What if you’re silently skipping asserts during your CI smoke tests because the jvm flag was missed, but now you think you’ve got the extra protection of those asserts?
I could be wrong but assert used practically everytime while writing unit / integration tests. Practically every test contains form of asset, could be standard Java assert keyword, or, more often JUnit Assert class.
I’ve never seen a unit test using the assert keyword, only the JUnit Assert class methods. It throws AssertionError so it is like the assert keyword but can’t be disabled like the assert keyword.