Logging or debugging
Debugging is lame. You should debug log.
If your code is structured you do not need debug logging.
These are two opinions from the two ends of the line. I am, as usually, standing in the middle, and I will tell you why.
First of all, there is no principal difference between debugging versus logging. They are just two different implementations of the same thing: observation of your execution engine state in time dimension.
1.1.1. Issue with debugging
When you debug you step your program forward in time and at any point the execution stops you can examine the value of any variable. The shortage is that you can not step back in time. At some points you realize that you would just like to see what the value of a certain variable was just before some method was called, some object was created or whatsoever happened in the system. What you actually do in such a situation is to restart the code and hoping it behaves deterministic try to catch the execution at the earlier stage that you are interested in. And this is another shortage of debugging. You can not effectively debug a code that does not behave deterministic. And trust me: most bugs behave non deterministic.
1.1.2. Issue with logging
With logs the major issue is different. It is not the time but rather the breadth of states, variables that you can look at is the problem. You insert log statements into your code dumping the values of variables into a log file at a certain point of execution. When you examine the log file you can scroll back and forth. However if you did not print out the value of a certain variable at a certain execution point, there is no way to get it from the log file. The solution is the same as with debugging: execute the code again, this time extended with the new log statements. If, however, you have enough information in your log files, then you will just get enough information to track down a bug even if that is not deterministic. Only 'if you have' …
1.1.3. Solution: logging all the states all the times?
The ideal solution would be to dump all variables into a possibly binary log file at each state of the execution and examine the content of the file afterwards. The examination would essentially look like a debugger, except that the change of the variables comes from the recorded log file instead of from on the fly calculation. It would be like a playback of a recorded execution and as such you could replay it several times. I do not know if there is any tool like that for the JVM.
You just can not define what is "each state" effectively in a multi thread execution environment like the JVM is. This is one of the issues. The other thing is that if you’d start dumping the JVM memory after each command (forgetting the issues of multi-thread) it would require enormous amount of bandwidth and disk space.
Dreaming about the ideal solution not deliverable is sort of no use. What is the solution that can practically be executed?
1.1.4. Practical approach
You can debug when it is appropriate. Full stop. You just did that so far, keep doing that. I tend to use log statements even when I debug some code and if the environment allows it I do it on the fly. When I find the root cause of the issue I am hunting I review the log statements and I delete them. They did the job while debugging, they are not needed anymore. At least that was my practice unit I found myself writing log statements that I have already created before. Why? Because fixing one bug does not mean that I have fixed all of them. There is nothing like all bugs fixed. But the log items littered the log file and that just increased the work to find the needed information hunting the next bug. In other words the log file is full of noise and that is why I deleted these items the first place. But for the same reason I could also delete the unit tests that already pass. It would save a lot of time during compilation, wouldn’t it? We do not do that.
Summary in one sentence? Log and debug the way it fits you and the issue you are hunting.
Comments imported from Wordpress
Peter Verhas 2014-03-05 10:40:08
Thanks for pointing that out. In some exceptional cases you may be able to debug production but that is and should not the general practice.
Logging or Commenting ? | Java Deep 2014-06-25 11:59:58
[…] my recent article was republished on dzone Jonathan Fisher added a valuable comment […]
Richard Fearn 2015-06-22 01:33:01
The shortage is that you can not step back in time.
The "Drop To Frame" feature in the Eclipse debugger goes some of the way to letting you do that:
…though it doesn’t reset variables back to their previous values. Still, it does let you re-run code if you realise you’ve stepped too far.
The ideal solution would be to dump all variables into a possibly binary log file at each state of the execution and examine the content of the file afterwards. The examination would essentially look like a debugger, except that the change of the variables comes from the recorded log file instead of from on the fly calculation. It would be like a playback of a recorded execution and as such you could replay it several times. I do not know if there is any tool like that for the JVM.
That sounds like Chronon to me:
Comments
Please leave your comments using Disqus, or just press one of the happy faces. If for any reason you do not want to leave a comment here, you can still create a Github ticket.