You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in the JDK, an failed assert will throw an AssertionError. Because the default uncaught exception handler doesn't have any kind of handling of AssertionError, this means that there's no logging or tracking of a failed assert past the stacktrace.
On top of that, assertions are only enabled if you have -ea set in the Java runtime.
On one hand, this makes assertions a pain in a live environment. On the other hand, enabling assertions in a test suite could be a great way to add extra conditions and terminate early without binding junit code directly into executable code -- a junit assert can happen in a test, but you can stick assert anywhere in the codebase.
Assertion handling in particular is far more interesting than the documentation makes it out to be.
For example, you can turn on assertions dynamically for a package or a single class, using the classloader! Sadly only seems to apply when the class is first loaded, so you can't change it after that (or can you?)
At the very least, assertions should trigger a dump of diagnostic logging statements associated with the thread, i.e. from Blacklite so that the operations leading up to the assertion are visible.
The text was updated successfully, but these errors were encountered:
wsargent
changed the title
AssertError should log as a fatal error
Define default logging for uncaught exceptions, especially asserts
Oct 31, 2021
Currently in the JDK, an failed assert will throw an
AssertionError
. Because the default uncaught exception handler doesn't have any kind of handling ofAssertionError
, this means that there's no logging or tracking of a failed assert past the stacktrace.On top of that, assertions are only enabled if you have
-ea
set in the Java runtime.https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html
https://docs.oracle.com/javase/11/docs/api/java/lang/AssertionError.html
http://www.javapractices.com/topic/TopicAction.do?Id=229
On one hand, this makes assertions a pain in a live environment. On the other hand, enabling assertions in a test suite could be a great way to add extra conditions and terminate early without binding junit code directly into executable code -- a junit assert can happen in a test, but you can stick
assert
anywhere in the codebase.Assertion handling in particular is far more interesting than the documentation makes it out to be.
https://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html#design-faq-general
For example, you can turn on assertions dynamically for a package or a single class, using the classloader! Sadly only seems to apply when the class is first loaded, so you can't change it after that (or can you?)
https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#setPackageAssertionStatus-java.lang.String-boolean-
At the very least, assertions should trigger a dump of diagnostic logging statements associated with the thread, i.e. from Blacklite so that the operations leading up to the assertion are visible.
The text was updated successfully, but these errors were encountered: