debugAlmost everybody is well equipped with logging essentials. But, only a few understand the purpose and power of the debug logs. Lets just refresh our basics as far as debug logging is concerned. To me personally, a best practices reminder time to time, inspires me to write quality code.


The basic idea behind debug logs is providing extra information which might prove crucial for debugging and troubleshooting an issue.


  • Its hard to estimate the exact nature of the issue that one might face related to a feature one is implementing. So, all information you think might be useful for tracking is useful.
  • Its easy to update the log levels and enable debug log level only for a certain section of code where the problem lies. So, one should try his best to provide as good a picture of the flow as he can.
  • So, log everything you can about the implementation, just don’t go berserk.

NOTE: Cherry picking makes life easier sometimes, because setting debug level application wide may result is too much information.


Yes, it is exactly what you think what it is, until it proves to be a savior when it saves hours of debugging. Impeccable debug logs are nothing less than a sequence diagram/documentation of the control flow.


Detailed logging doesn’t sound very maintainable? Well, it isn’t. Logging is a feature in itself and takes a considerable amount of time of the implementation. One has to be very careful when updating the logic for a method with loads of debug logs, as the debug logs might need update as well. Debug logs are similar to documentation when it comes to maintainability. In fact, the difference between the two is,

Documentation answers: What will happen? Debug logs answer: What is happening/happened?


Now that we know debug logging is not just important, but indispensable. When does it grow and takes a toll on the performance of the system?
It is pretty obvious that the debug logs are only for the developers and must be switched off when deploying to production.

  • Even the logger is set to skip the debug logs, it will have to check the debug level is enabled or not, also delegation may make it a little expensive.
  • Performance also depends on how we use the logging.
    • Concatenating large number of immutable strings is a major problem.
    • Several logging statement logging to the same log levels must be clubbed into a single if block. The if block must check if the particular logging level is enabled or not.
      if (LOG.isDebugEnabled()) {
          LOG.debug("Some very important debug log.");
          LOG.debug("Another crucial debu log." + "But, doesn't take care" + " of immutable strings " + "being concatenated.");
          LOG.debug(veryLargeObject); // toString method will kick in here

      ** This ensures that the logger is not forced to check for the log level being enabled several times.
      ** Sometimes the log message generation is expensive. Immutable string concatenations, generating strings using the toString method of the instance. For such cases as well, isDebugEnabled check if cost effective.


Debug logs as trivial as which method is being called, and with what parameters can be automated using the aspect oriented programming with aspectJ. So, one should not waste time in debug logging these trivial information.