Design FAQ - The AssertionError Class

1. When an AssertionError is generated by an assert statement in which Expression₂ is absent, why isn't the program text of the asserted condition used as the detail message (e.g., "height < maxHeight")?

   While doing so might improve out-of-the-box usefulness of assertions in some cases, the benefit doesn't justify the cost of adding all those string constants to .class files and runtime images.

2. Why doesn't an AssertionError allow access to the object that generated it? Similarly, why not pass an arbitrary object from the assertion to the AssertionError in place of a detail message?

   Access to these objects would encourage programmers to attempt to recover from assertion failures, which defeats the purpose of the facility.

3. Why not provide context accessors (like getFile, getLine, getMethod) on AssertionError?

   This facility is best provided on Throwable, so it may be used for all throwables, and not just assertion errors. We intend to enhance Throwable to provide this functionality in the same release in which the assertion facility first appears.

4. Why is AssertionError a subclass of Error rather than RuntimeException?

   This issue was controversial. The expert group discussed it at length, and came to the conclusion that Error was more appropriate to discourage programmers from attempting to recover from assertion failures. It is, in general, difficult or impossible to localize the source of an assertion failure. Such a failure indicates that the program is operating "outside of known space," and attempts to continue execution are likely to be harmful. Further, convention dictates that methods specify most runtime exceptions they may throw (via "@throws" doc comments). It makes little sense to include in a method's specification the circumstances under which it may generate an assertion failure. Such information may be regarded as an implementation detail, which can change from implementation to implementation and release to release.