At the time the feature was added, there was no way to make a parameter to a function be lazily evaluated. Something like `assert(condition, "error: " + stuff)` would eagerly concatenate the string even when the condition is always true (which it should be). Nowadays, the error parameter can be specified as a lambda, which can potentially be optimized to be just as cheap as the existing assert feature.

You can disable them at runtime (e.g. in prod) to avoid the performance overhead once you're satisfied the codebase is thoroughly enough tested.

For some things like requiring arguments to be non-null static checks with annotations have superseded them (in a confusing way inevitably - I think there are three different common non-nullness annotations).

The pros are that it can generate better error messages, without putting that responsibility on the programmer. Something that would otherwise require a preprocessor or some form of metaprogramming.

I'm wondering this, too.

There's Guava and its Preconditions class[0] that is approximately as terse and I find to be more helpful than everything-is-an-AssertionError.

[0] https://guava.dev/releases/14.0/api/docs/com/google/common/b...