logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Tonhofer, m-plify S.A." <d.tonho...@m-plify.com>
Subject Re: Example policies for log levels?
Date Wed, 08 Dec 2004 11:09:22 GMT
> Any little hint...

Sure.

Just my two cents about what happens at my place: There is no strict
policy on level usage, it depends on what the developer's tastes
are. Often, you will find yourself fine-tuning the levels once the
program is running, moving some INFOs down to DEBUG, some DEBUGs
to INFO etc. You may want to check for special circumstances that
allow you to suppress logging. This can yield convoluted stuff like
this:

public void run() {
 Logger logger = LOGGER_mini_run;
 miniThreads.put(this, this); // put ourselves into the MiniThread hashtable
 try {
   InputStream is = clientSocket.getInputStream();
   OutputStream os = clientSocket.getOutputStream();
   // the beef
   handleCommunication(clientSocket, is, os);
   // on return, socket & streams might already have been closed
   // but make sure that everything has been closed anyway
   try {
     os.close();
   } catch (Exception exe) {
     // this is not considered mortal, thus just info
     logger.info("Barfed while closing output stream", exe);
   }
   try {
     is.close();
   } catch (Exception exe) {
     // this is not considered mortal, thus just info					
     logger.info("Barfed while closing input stream", exe);
   }
 } catch (SocketException exe) {
   if (exe.getMessage().trim().toLowerCase().startsWith("socket closed")) {
     // this is consider a minor problem
     logger.info(exe.getClass().getName() + ": " + exe.getMessage().trim());
   } else if (exe.getMessage().trim().toLowerCase().startsWith("connection reset")) {
     // this is consider a minor problem
     logger.info(exe.getClass().getName() + ": " + exe.getMessage().trim());
   } else if (exe.getMessage().trim().toLowerCase().startsWith("Broken pipe")) {
     // this is consider a minor problem (added 2004-08-04)
     logger.info(exe.getClass().getName() + ": " + exe.getMessage().trim());
   } else {
     // this may be normal or not....
     logger.error("Barfed while handling connection", exe);
   }
 } catch (SilentSocketServerThreadException exe) {
   // this is an exception that should not be logged...so we don't (e.g. the
   // password was bad but no-one cares)
 } catch (Exception exe) {
   // this may be normal or not....
   logger.error("Barfed while handling connection in " + Thread.currentThread().getName(),
exe);
 } finally {
   closeClientSocketSecurely(clientSocket); // note that it might take some time until the
client notices
   miniThreads.remove(this); // remove ourselves from the MiniThread hashtable
 }
}

We have very fine-grained logging categories however, generally
each method has its own category, like this:

 some.package.class.method

so fine-tuning *also* takes place in the runtime log4j config, mainly
when maintenance comes in and say 'I have around 400 WARN messages
in my inbox - isn't there something you can do?'

Now, the repartition of logging instructions by level:

- DEBUG: A lot, as they are very useful during development,
         (dare I say that it's cool to see the program actually do
          something). The messages are often very verbose and may
         include full dumps of datastructures, so you have to guard
         them with if (logger.isDebugEnabled()) { ... }
- INFO:  A lot, messages are often of a type that might
         be of interest to customers/end users (if the customer says
         'does it work' or 'what is it doing now' then you know
         you want an info log at that place)
- WARN:  Some. Stuff that goes wrong but that you hope can still be
         handled properly by the program is logged with WARNs. Often,
         failed double-checks of values are causing WARN messages.
         For example, instead of inserting an assert(x > 0) instruction,
         which may be too radical you would try to continue in an
         optimistic manner:

         if (x <=0 ) {
           logger.warn("ZOMG!! x<=0! Fixing! But you better check your code!!");
           x=0;
         }

- ERROR: Wherever necessary. Stuff that goes seriously wrong, in particular
         all 'unexpected' Exceptions/comm problems/database problems etc.
         The program may or may not know how to handle those but the operator/user
         MUST be told about it.

- FATAL: They are generally not used in our case, except maybe at the topmost
         'catch'.

-- David Tonhofer

   M-PLIFY S.A.

--On Wednesday, December 08, 2004 7:57 AM +0000 Fredrik Jonson <fredrik@myrealbox.com>
wrote:

> On 2004-12-07, Keith Hatton <khatton@axiomsystems.com> wrote:
>
>> > I'm wondering, is there any article or document available that
>> > discuss how to decide on which log levels is suitable for what kind
>> > of application errors?
>>
>> Just my $0.02.  I agree with your use of FATAL, ERROR and DEBUG.
>> I also use ERROR in some cases when logging something that has gone
>> wrong, even though the result is predictable.
>
> Ok, when thinking about it, to me, that'd be a WARN. I only didn't
> implement it that way in my log4j trials. Doh on self. =)
>
>> I use WARN for things that should not cause the application to fail,
>> but are not the "expected" use case, and may cause unexpected (though
>> correct) behaviour, or some quasi-anticipated exception conditions
>> that are fully recoverable and normally down to "user error".
>
> Seems sensible.  Thanks for your input!
>
> Anyone else feel like pitching in? I mean, when implementing an advanced
> logging service, with ready-to-use loglevels, there must have been some
> motivation when choosing those loglevels? Any little hint...
>
> --
> Fredrik Jonson
>



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message