How do I know if my program runs with assertions

D

dgront

Hi,

I am using assertions to test my code. I am also using
java.util.logging which on regular basis writes only the most
important messages.

What I need is to increase verbosity of logging (and forward the
massages to System.err) when JVM is running in assertion mode, i.e. -
ea flag has been used.

I wrapped java.util.logging.Logger in my own object as a singleton,
which starts in a static initialization block so it happens on the
very beginning of the program. I would like to put the stuff there,
i.e. the part that detects assertions and changes the behaviour of my
logger.

Best regards,
Dominik
 
M

Mark Rafn

dgront said:
What I need is to increase verbosity of logging (and forward the
massages to System.err) when JVM is running in assertion mode, i.e. -
ea flag has been used.

Generally, this is a bad idea - you're conflating two different things: level
of log reporting, and level of invariant checking. You'd usually be better
off setting them separately, which is pretty easy to do.

Just use different levels of logging (log.debug, log.info, etc.), in your code
and at runtime you can set what levels are loggged to what destinations.

Keep in mind that logging, like assertions, can be controlled by class or
package, not just the entire program.
i.e. the part that detects assertions and changes the behaviour of my
logger.

If you really must, there are a few ways you can do so. You can put code
inside an assert:
assert setDebugLogging();
and it will only be called if assertions are enabled for that class when the
code executes.

Or you can use getClass().desiredAssertionStatus() to see what the asserion
status would be for the class if it were loaded now.
 
L

Lew

dgront said:
I am using assertions to test my code. I am also using
java.util.logging which on regular basis writes only the most
important messages.

What I need is to increase verbosity of logging (and forward the
massages to System.err) when JVM is running in assertion mode, i.e. [sic]
-ea flag has been used.

I wrapped java.util.logging.Logger in my own object as a singleton,

Why? That defeats part of the purpose of Logger. Loggers are tunable
on a class-by-class basis, if you name them for the classes in which
they appear.
"The [logging] namespace should typically be aligned with the Java
packaging namespace ..."
<http://java.sun.com/javase/6/docs/technotes/guides/logging/
overview.html>

Assertions are also enabled on a class-by-class basis.
which starts in a static initialization block so it happens on the
very beginning of the program. I would like to put the stuff there,

I prefer to make loggers instance variables. You can initialize
static loggers (if you use those) in the static initialization block
of the classes that use them (virtually all your classes). I
initialize instance Logger variables in the instance initializers.

A static initializer does not run at "the very beginning of the
program", it runs when the particular class is loaded, and that
doesn't happen until the class is referenced in a particular way.
<http://java.sun.com/docs/books/jls/third_edition/html/
execution.html#12.4>
i.e. [sic] the part that detects assertions and changes the behaviour of my
logger.

"Detecting" assertions isn't done in the static initializer, but
"... prior to the execution of any field initializers for class
variables (§8.3.2.1) and static initializers (§8.7), the class's class
loader determines whether assertions are enabled or disabled ...".
<http://java.sun.com/docs/books/jls/third_edition/html/
statements.html#14.10>

Assertions are enabled or disabled on a class-by-class basies.

Set the logging level and assertion levels extrinsically to the
program. For example, you can modify the logging configuration file
<http://java.sun.com/javase/6/docs/technotes/guides/logging/
overview.html#1.8>
whenever you plan to run with "-ea".

Another way is to assert a logging initialization method that returns
'true'.

assert setDetailedLogging();

This will only execute the method when assertions are enabled, and if
you write the method to return 'true' it will not throw an
AssertionError.

This will work equally well with a static method for static loggers or
an instance method for instance loggers.
 
M

Mark Space

Mark said:
Generally, this is a bad idea - you're conflating two different things: level
of log reporting, and level of invariant checking. You'd usually be better
off setting them separately, which is pretty easy to do.

Mark Rafn makes a good point. It should be possible to use the logger
normally, then when you want output to System.err, configure the
..properties file to send output to System.err (I think the
ConsoleHandler does this by default). Loggers have multiple handlers,
you can send logging to System.err and a file very easily just by
rejiggering the .properties file. This is a huge win because you don't
have to recompile (and re-test) code.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top