>if(logger.isDebugEnabled()) {
> logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i])); }
>Personally, I think that is an absolute abomination, and a major failure
>of the logging framework / Java combination.
It certainly makes the code ugly. If I am going to use an "isDebugEnabled"
check, I try to put as much logging in there as possible. If the check
begins to appear three or four times in a method, I usually begin to wonder
if the method is over-complex or if I am logging entirely the wrong stuff.
If I am just logging a string plain message (e.g. "Connection closed" or
whatever) I just log it, I feel the "isDebugEnabled" check is an overhead in
this simple case.
If there is any processing or method calls in the log message, then that
should be in a guard for performance.
> And yes, I have been pointed to Aspect compiler solutions (Almost
passable).
I have also wondered if it would (somehow) be possible to use Aspects to
"load in" different logging strategies, thus keep the method clean and doing
what it is supposed to do. Although I have not yet had time to investigate
Aspects beyond reading the "Idiot's Guide".
I wrote a very crude FindBugs detector (and I do mean CRUDE!) to look for
classes with no logging, and complex logging (as in your example) without
the appropriate "Enabled" guard. I should really go back and clean that up
at some point. It certainly was an eye-opener when I pointed at a few
people's code... :o)
J.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
