Logging Antipatterns

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.

Related Whitepaper:

Best Practices for Secure Software Development

Best practices for all organizations that would like to produce more secure applications!

As part of the software development process, security professionals must make choices about where to invest their budget and staff resources to ensure that homegrown applications are as secure as possible. ESG research found organizations that are considered security leaders tend to make different choices than other firms.

Get it Now!  

Leave a Reply

Submit Comment

− 4 = three

.NET Code Geeks and all content copyright © 2010-2015, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on .NET Code Geeks are the property of their respective owners.
.NET is a trademark or registered trademark of Microsoft Corporation in the United States and other countries.
.NET Code Geeks is not connected to Microsoft Corporation and is not sponsored by Microsoft Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

Get ready to Rock!
To download the books, please verify your email address by following the instructions found on the email we just sent you.