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 <[EMAIL
PROTECTED]> wrote:
On 2004-12-07, Keith Hatton <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
