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.
-
1pretty subjective. Perhaps Community Wiki would be appropriate? – bmargulies Dec 30 '09 at 04:04
8 Answers
In general, I follow these guidelines:
- DEBUG : low level stuff. cache hit, cache miss, opening db connection
- INFO : events that have business meaning - creating customer, charging cc...
- WARN : could be a problem but doesn't stop your app. email address not found / invalid
- ERROR : unexpected problem. couldn't open db connection. etc...

- 8,941
- 2
- 30
- 32
-
log4j also has a [FATAL](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#FATAL) level and a [TRACE](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html#TRACE) level. For log4j2 see [this page](https://logging.apache.org/log4j/2.0/log4j-api/apidocs/org/apache/logging/log4j/Level.html) – D.B. Oct 08 '16 at 01:07
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.

- 10,171
- 9
- 55
- 72
-
Also, NHibernate uses INFO level to log every SQL statement it generates which is irritating as I tend to leave INFO on by default in production systems. This should be DEBUG IMHO. – Andy May 21 '12 at 08:18
-
I agree with the list of meanings, but I have a very different understanding of System.out/err (which is Unix-shell based: out is for "the output the user was hoping for," while err is "stuff that might help if the app doing the logging needs fixing". As such, *all* log4j output is System.err stuff; command-line apps send their System.out stuff to System.out; webapps send their System.out stuff to the web response DTO). It might be better just to remove or ignore the "My baseline" paragraph. – jackr Jan 26 '18 at 19:53
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.

- 97,814
- 39
- 186
- 310
-
Hibernate is actually not such a great reference for that IMO, see for example the link in my answer. I think spring is a good example, as well as quartz, axis2 and similar projects – Yoni Dec 31 '09 at 07:25
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.

- 425
- 4
- 5
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

- 955
- 3
- 11
- 19
Here are some guidelines I use:
- TRACE: verbose logging for very low level debugging, things I would not normally need to see in a log unless there is some very obscure or unusual issue.
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.

- 4,523
- 2
- 19
- 39
ERROR logging should always be on.
INFO + DEBUG should be on when tracking down problems/bugs.

- 295,962
- 43
- 465
- 541
-
Does he mean 'use' as in 'enable' or 'use' as in 'which do I call when'? – bmargulies Dec 30 '09 at 04:06
-
Thanks for the reply. From your response I read that ERROR is the level that should be used in Production and INFO / DEBUG needs to be set depending on requirement in case of troubleshooping. Pleae clarify whether I am correct. – Eager Learner Dec 30 '09 at 04:09
To what others mentioned, I'd add TRACE and FATAL levels, the former is good for very verbose logging, the later is to indicate total show stopper. There are general guide lines on how you use levels, as mentioned by other above. However, the most important is how YOU will use it and how your USERS will interpret them. You need levels to focus on problems, so decide what is the problem in your case. Your users will hardly ever need trace or debug statements, but they will definitely want to nail problems and report them to you.

- 4,068
- 4
- 38
- 47