[slf4j-dev] Re: TRACE level
Ceki Gülcü
listid at qos.ch
Tue Jul 5 18:14:12 CEST 2005
At 04:43 PM 7/5/2005, Greg Wilkins wrote:
>Ceki,
>
>I'm a bit both ways about the marker mechanism.
>On one level I see that it is cool and flexible - I specially like the nested
>marker bit. Markers are a bit like log levels - except a hierarchical name
>space is easier to manage than a numeric space.
>
>But then I see some problems....
>
>
>Firstly - I can see how it applies to debug, but I don't think it
>applies well to info, warn, error, etc.
>I would never say:
>
> logger.warn(HEADER,"msg",e);
>
>So do markers only apply to debug?
No, markers can apply to all levels. For example, if a particular
error needs to be escalated to processing by the database
administrator, you can mark the associated log messages with a
specific marker, say DB_ERROR.
try {
write_to_db();
} catch() {
logger.error(DB_ERROR, "Could not write to database.", e);
}
One could configure the logging system to send an alarm to the DB
administrator's for logs marked as DB_ERROR. One could further
customize certain log messages (by adding more markers) so that the DB
admin receives them on his beeper.
Your could also mark certain errors as "minor" and filter them
differently than unmarked (regular) errors.
Markers are not numerically ordered. So you can mark log statements in
ways not allowed by a strict order.
>This is the same problem with nested loggers. I want a multiple levels
>of debug - but I have no use-case for multiple levels of warn, info etc.
Given the new possibilities, there may be uses that have not yet
crossed your mind.
>Markers seam a little heavy weight just to have multiple levels between
>info and nothing.
The Marker approach may indeed by a little heavy weight.
>Also it is important to be able to do:
>
> if (logger.isDebugEnabled(HEADER))
> {
> logger.debug(HEADER, "Headers follow.");
> for(int i = 0; i < header.length; i++)
> logger.debug(HEADER, "{}: {}", header[i].getName(),
> header[i].getValue());
> }
>
>But I'm not clear if that will be possible?
Sure, the org.slf4j.Logger interface would need to be enhanced. I did
not discuss the isDebugEnabled(Marker) method in my previous example
in order to focus on the essentials.
>Also I do like the simplicity and clarity of
>
> try
> {
> Object answer = theQuestion();
> log.debug("got the answer.");
> log.verbose("answer = {}",answer);
> }
> catch(Exception e)
> {
> log.ignore(e);
> }
>
>
>It is not quiet the same to have
>
> class LogSupport
> {
> static final String IGNORED_MSG="Ignored {}";
> static final String IGNORED="Ignored";
> static final Marker STACK_TRACE=Marker.getMarker("stack trace");
> static final Marker VERBOSE=Marker.getMarker("verbose");
> }
>
>and then do
>
> try
> {
> Object answer = theQuestion();
> log.debug("got the answer.");
> log.debug(LogSupport.VERBOSE,"answer = {}",answer);
> }
> catch(Exception e)
> {
> log.debug(LogSupport.IGNORED_MSG,e.toString());
> log.debug(LogSupport.STACK_TRACE,LogSupport.IGNORED,e);
> }
Only one log statement in the catch block should suffice. No need to
have two of them.
Unless the user instructed otherwise, the logging system would
automatically suppress the stack trace for messages marked with the
STACK_TRACE marker.
Thus, you could just write
try
{
Object answer = theQuestion();
log.debug("got the answer.");
log.debug(LogSupport.VERBOSE,"answer = {}",answer);
}
catch(Exception e)
{
log.debug(LogSupport.NO_STACK_TRACE, "Caught exception" , e);
}
You could replace the message "Caught exception" with something more
appropriate. The important point to note is that it's a regular string
without accolades.
If your LogSupport class was appropriately enhanced, you could shorten
the catch block to:
catch(Exception e)
{
LogSupport.NSDebug(log, "Caught exception" , e);
}
BTW, it's a joy to participate in exchanges of this quality. Thanks to
all for their open mindedness and quality of participation.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
More information about the slf4j-dev
mailing list