As we hopefully all agree good logging is a great asset. Yet I come across aweful styles of logging (and sometimes produce them myself). So I guess it is time for a small Antipattern collection.
No Logging at All
- Exception Handler without any code are an obvious example of this, but reading a configuration file without giving a hint which whan you are reading and what you found in it also belongs in this category
- Wrong Log Level
- logging the discovery that you can’t connect to the database of the application in DEBUG level, or logging entry and exit points of method with ERROR level are typical examples. Always remember: Once in production the log level will probably risen to WARN or ERROR and you gonna still want to see the important messages, don’t you?
- Catch Log Throw
- In a catch block the exception gets logged and then thrown again, possibly wrapped in a new exception. When this anti pattern is used in many places the result is a log file that contains every stacktrace in a dozen repetitions and variations. A nightmare when you try to understand what is going on.
- Logging to stderr or stdout
- System.out.println and ex.printStacktrace() are easy and fast to write, but their result will probably disappear in /dev/null once your application is running on a production server.
- Complex Logging Statements
- When the message for logging gets constructed in a convoluted way with lots of function calls, there is a serious risk that you end up with a NullPointerException instead of a proper logging entry. This is especially true when we try to log inside a catch block. After all something went wrong in the first place, so NULL values a everywhere
References: Logging Antipatterns from our NCG partner Jens Schauder at the Schauderhaft blog.
