Doug Cutting wrote:
Nigel Daley wrote:
Just a caveat: when there is conditional code like this
based on the configured logging level, then testing
should be done with different logging levels to
verify that there are no side effects or exceptions
(such as NPE) generated by these conditional code
blocks. FWIW, this is not something I currently consider
in my test matrix.
We could test this by running unit tests at DEBUG, but I also think
it's fair to declare that we only support running the code at
particular log levels. Running things at DEBUG level can affect
timing and scalability, and things probably won't work as reliably in
all situations, even without bugs in the logging code.
Doug
Log4j has is<Level>Enabled() methods to check for a certain debugging
level. However as expected the logging functions such as info() or
debug() also checks for the debugging level being enabled.
A very frequently asked question is why would somebody use the test
is<Level>Enabled before a logging statement, since the function already
checks this. But prior checking avoids argument computation. For example
a statement like
log.debug("start:" + someclass.getStart() + " end:" + someclass.getEnd());
should be guarded by checking the log level, since the string
"start....." will always be computed regardless of debug level being
enabled.
But IMO if the argument to the logging function is straightforward,
there is not need to clutter the code with code guards.
