Hi Tushar,
I have to disagree on the run-time cost. One of the nice things about log4j
is that there is very little overhead for a call to log4j when logging is
disabled for that class or category. Further, if it is expensive to generate
a log statement, you can do this:
if( category.isDebugEnabled() )
{
String logMessage = <<... expense stuff ...>>;
category.debug( logMessage );
}
I agree that too many logging statements can make the code hard to follow
and this should be avoided. As far as breaking code with log messages --
this could be possible if any methods called while generating a logging
message have side effects. Also cryptic log messages are of little use.
One practice that we used on my last project with log4j was to log whenever
we threw an exception, and log whenever we caught and handled an exception.
I'm a big fan of log4j's ability to surgically turn on and off logging based
upon categories.
Another thing that we did was to create the category structure the same as
the class/package structure. Each class can have a static data member:
private static Category log = <MyClassName>.class.getName();
This is safe because Category objects are thread safe. Then you can turn on
logging by the class or package.
Regards,
Eric Meyer
: I have mixed views about random Log4J statements spread throughout the
: code. It adds significant debugging capabilities for the developer of a
: class but may not be very useful for others using the classes. There is
: also a performance penalty associated with using these. Also there is the
: additional risk of code breaking because of the debug statements. In my
: perspective use them - but with a little bit of care. Would anybody like
to
: recommend standards as to how to use these.
:
: -Tushar
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
