What is the best practice in using log4j levels while coding. I mean when do we use INFO logging, when do we use DEBUG logging / ERROR logging etc.
相关问题
- convert logback.xml to log4j.properties
- logging static methods in a parent class
- Wrap log4j or create custom logger?
- ClassNotFoundException found in Log4j 2.0
- Undeploying a Grails App from Glassfish gets a Cla
相关文章
- Can IntelliJ create hyperlinks to the source code
- how can I disable output to log4j.rootLogger?
- Log4j2 using {} against using %d or %s
- How do I redirect a javaw.exe console output to a
- log4j: Standard way to prevent repetitive log mess
- Log4j2 not working in WebLogic 12.2.1
- Grails and Log4J : How to logs in different files
- Managing a Large Number of Log Files Distributed O
TRACE: The least level of log. Provides most detailed level of information.
DEBUG: Log statement here are meant to help developers. Detailed state of your application.
INFO: General business information. Progress and state of your application
WARN: Warnings about unexpected events. These are not serious enough to abort your application.
ERROR : Serious problems in your application.
Also having the right level of logging turned on in different environments is equally crucial.
In general, I follow these guidelines:
My baseline is always that INFO level is equivalent to System.out, and ERROR is equivalent to System.err.
DEBUG - Here you put all your tracing information, and specifically information that you don't want to see when your "comfort level" is system.out.
INFO - use this one for general messages, progress messages, for application related messages, but not for tracing.
WARN - provide alerts that something is wrong, perhaps unexpected, or that a workaround is used, but the application can still continue (socket timeout/retries, invalid user input, etc.).
ERROR - alerts about problems that prevent your app from continuing normally, e.g. database is down, missing bootstrap configuration.
A common mistake when writing libraries is to use ERROR level to indicate problems with the calling application (the code that uses the library) instead of indicating real errors within the library itself. See for example this hibernate bug -> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3731
This is really annoying because messages from ERROR level are really difficult to suppress, so use them only to indicate problems with your own code.
All - I don't really use this one, it is practically the same as DEBUG or TRACE.
Despite this question is pretty old, this is really an important point that every developer should know, I highly recommend you to check the official page of Apache log4j.
Also I have found and useful image that describes this perfectly, log4jImage taken from supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/log4j/log4j.html
Here are some guidelines I use:
DEBUG: logging intended for developers' eyes only - contents of variables, results of comparisons, and other bits of information that help debug business logic.
INFO: high level information such as task X is now complete or some rule is satisfied and here is what I'm going to do next because of that rule.
WARN: there might be a problem but it's not severe enough to do any real harm to the flow of the business logic. For example maybe some variable is sometimes going to be null but we don't necessarily need it or we can work around it somehow. At the same time we still want to know about it just in case we're told later we need to find examples of it or investigate more carefully why it happens.
ERROR: A serious problem that definitely needs to be investigated further, but not serious enough to stop the application from accomplishing the task at hand.
FATAL: A very serious unexpected problem that we can't work around or recover from and may even prevent the application from doing something useful.
The best way to learn is by example. Read source of some open source things, like, oh, Tomcat or whatever is in your application area, and see what you see.