[slf4j-dev] Re: Ignore method.

[Greg Wilkins]

Comments in-line
Ceki Gülcü wrote:
> 
> Greg,
> 
> For the moment, I'd like to pursue the discussion regarding ignore()
> and ignore (pun intended) the trace debate.

Good idea... 

> 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)
>       logger.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..

Exactly, but I would say:

 Given that stack traces are verbose, expensive to generate and most developers 
 are alarmed by the sight of them, by default, we would like ....



> 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 agree that the API should consider an ignore method as *marking* a certain log.
It is then up to the implementation/configuration of the particular logger
as to how that log is rendered - just as for all logs.

The important aspect to capture is that the API should be able to
mark a passed exception as something that the program has ignored.


> 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.

cool.

cheers

 
> 
> 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);}
> 
>