I really like the Oracle tutorial on Java asserts.

https://docs.oracle.com/javase/8/docs/technotes/guides/langu...

And I'm pretty happy with its design considering its age.

Notably this is not a function call and indeed things are not called unless you enable it. Contrast with Zig. So I guess you will only suffer from code bloat if you never enable them.

The tutorial mentions the dangers of side effects. But it also mentions how to use them for more complicated assertions. That's natural since you'll want something like that when you need to check a post-condition.

Programming assertions get joked on because of, ahem.

- Step one: Turn on extra checks in test environments where the stakes are low

- Step two: Turn them off in production (with realistic data because prod eq. reality) to save cycles

And that seems to be partially accurate. However the truly interesting assertions can test complex conditions that might break complexity (Big O) contracts. Like a private mininum function that is advertised as O(1) on account of taking a sorted list. But there is no type guarantee that the list is sorted. So you assert that it is sorted. But that breaks the complexity contract.

Overall I have not used assertions in Java for trivial conditions in like five years. They're better deployd for something more complex than that.

Then there is the whole thing about -- and more topics to be sure -- crashing the whole application or not. That's not necessarily great for us regular Java programmers. However we can (though discoraged) catch AssertionError if we want to.