[slf4j-dev] Ignore method.

Ceki Gülcü listid at qos.ch
Wed Jun 29 16:25:22 CEST 2005


Greg,

For the moment, I'd like to pursue the discussion regarding ignore()
and ignore (pun intended) the trace debate.

After carefully reading your commments, I was able to get a clearer
picture of the use case. Here is a reformulation of your comments as
requriements for a special use case.

Requirements
============

For example, when writing protocols, one often sees code of the
following form:

    try {
       // invoke somebody elses code or do some protocol stuff
       ...
    } catch(IOException e)
       loggger.debug("Caught exception", e);
    }

In this context, it so happens that when they occur, IOExceptions
affect only their particular connection but do not threaten the
stability of the whole system. As such, they are considered part of
normal operation, hence the use of the "debug" printing method.

Given that most developers are alarmed by stack traces, by default, we
would like to avoid printing out a stack trace for these type of
IOExceptions. Nevertheless, we would like to preserve the capability
to turn on printing stack traces for these exceptions if and when we
decide to do so.

I hope the above requirements faithfully capture your intent for the
use of the ignore() method..

Now, it seems to me that what you really want to accomplish is to
instruct the logging system to log *certain* exceptions logged at
level DEBUG, INFO or WARN without a stack trace. The user may decide
to override these instructions at a later time with the help of a
configuration file. In a nutshell, we want the stack printing
behavior to be configurable.

Putting on my log4j/nlog4j hat, the only problem I see is limiting the
omission of the stack trace for some exceptions but not others. The user
has to communicate this information by *marking* certain log
statements in a specific way. By the way, this is automatically
accomplished by the use of the ignore() method. I believe that this
marking needs to be done at the SLF4J level while the rest of the
requirements can be handled by the logging system internally.

I intend to come up with a concrete API proposal after certain
details are ironed out. In any case, thank you for your insightful
comments.


At 09:23 AM 6/28/2005, Greg Wilkins wrote:


>In writing protocols or application containers, ( when you run code that is
>supplied by others), I have often had the need for code like the following:
>
>    try
>    {
>       // invoke somebody elses code or do some protocol stuff
>       ...
>    }
>    catch(IOException e)
>    {
>       if (log.isDebugEnabled())
>       {
>           if (log.isTraceEnabled())  // or similar verbosity level
>             log.debug("IGNORED "+e);
>           else
>             log.debug("IGNORED",e);
>       }
>    }
>
>This is for exceptions that the programmer this will never occur.  These
>are for exceptions that are likely to occur, but that are ignored when
>they do.
>
>For example, in Jetty we get's lots of IOExceptions thrown when internet
>exploder closes connections mid response.  These are not errors or even 
>warnings,
>but simply normal operation.
>
>I know from experience that it is not sufficient simply to have a 
>log.debug("IGNORED",e)
>that reveals the exception if debug level is on.  90% of programmers 
>running with
>debug on are incapable of seeing a stack trace without reacting to 
>it.  Many will
>see the stack trace and simply will not see the IGNORED and start acting 
>like there
>is a problem.   Even if a programmer does pay attention to the IGNORED, 
>the sight
>of stack traces scrolling by is distracting and can obscure valuable 
>information.
>
>It is not sufficient to have just log.debug("IGNORED "+e) as you are never 
>100%
>certain that you don't need to see the stack trace.
>
>Back to the IOException from IE example, with debug on I like to see that the
>exception occured.  If I have verbose debug on, then I'd like to see the full
>stack trace.
>
>I like to see this provided as
>
>   log.ignore(Throwable th);
>
>But I can also do this is a support class like
>
>   LogSupport.ignore(Logger log, Throwable th);
>
>but only if there is a verbose log level that support class can use to 
>determine
>when to reveal the full stack trace.   However, I would really like to see
>the ignore method as it is a very very strong encouragement to avoid the 
>dreaded
>
>   catch(Exception e) {}
>
>and it would become the standard to have
>
>   catch(Exception e) {log.ignore(e);}

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/





More information about the slf4j-dev mailing list