The 5 Java logging rules | Java Code Geeks
Logging is a critical factor that should be always kept into account during the software development.
When something bad happens in production, the log files are usually the starting point of our fault analysis. And, often, they are the only information in our hands to understand what is happened and which is the root cause of the problem.
It is so very important to have the required information logged properly.
The following five logging rules are a way to check and, possibly, improve how we handle the logging in our code.
Please note that we will not discuss how to configure a logging engine nor we will compare them to each other.
Rule 1. Logging is for readers
The logging messages should be meaningful to who will read the log files, not only to who wrote the (logging) code.
It seem a very obvious rule but it is often violated.
For example, let's consider a log message like the following ERROR: Save failure - SQLException .....
Saving what? This message could mean something for the developer but it is completely useless for the poor guy which is looking at the production problem.
Much better message is ERROR: Save failure- Entity=Person, Data=[id=123 surname="Mario"] - SQLException....
which explains what you wanted to save (here a Person, a JPA entity) and the relevant contents of the Person instance. Please note the word relevant, instead of the world all: we should not clutter log files with useless info like the complete print of all entity fields. Entity name and its logical keys are usually enough to identify a record in a table.
Rule 2. Match the logging levels with the execution environment
All logging facades and engines available in the Java ecosystem have the concept of logging level (ERROR, INFO…), with the possibility to filter out messages with too low level.
For example, Java util logging uses the following levels: SEVERE, WARN, INFO, FINE, FINER, FINEST (+ CONFIG and OFF).
On the contrary, the two most popular logging facade, Apache Commons Logging and SLFJ, prefer the following levels: FATAL, ERROR, WARN, INFO, DEBUG, TRACE.
Logging level filtering should depends on which stage of the development is your code: logging level in the production should not be the same as in test/integrations environments.
Moreover, logging level should also depends on the code owner. In general our own application code should have a more detailed logging compared to any third party library we are using. There is no big meaning to see, for example, Apache Commons debug messages in our log files.
Read full article from The 5 Java logging rules | Java Code Geeks
No comments:
Post a Comment