Logging messages in your software is a great source of debugging information both before and after product release. Unlike conventional stack traces which create a lot of mess, creating log files keeps your applications output tidy whilst keeping all the important information about how the software is running. This can significantly aid in debugging at any stage of development and its impact on the user is minimal if non-existent. The reasons you should consider implementing a logging strategy are four
fold:
Logging increases debugging efficiency
Programmers debug software using various methods or approaches; printing out code statements to verify correct behavior, unit testing for correct behavior and the use of a software debugger; found in nearly all Interactive Development Environments (IDE) today. The latter is possibly the least efficient means of debugging so it is used as a last resort due to the timely nature required to step through code line by line, identifying where a bug or problem might exist. Although a last resort, it is sometimes the last form of debugging left when quicker debugging methods have failed to reveal the source of the problem.
For this reason, first pass debugging often involves printing out values or statements to verify correct behavior. Why? In most cases it is quicker than stepping through a debugger. This perception however is a little bit misleading. Whilst up front this method requires very little time, over time it can add up. Because these types of messages generally appear around or at the location of bugs in the software they are often removed after the bug or problem area has been resolved to not create extra noise in the programs output.
This has the side effect of removing any trail of information leading up to, or after the problematic execution point. If you have any problems around these areas at a late stage, you have no information available. You would have to print this information out again, squash the bug and remove the messages again. This is where logging can help save time.
By logging messages instead of printing them to a standard output stream (such as the screen) you don’t need to spend time removing them. You can log them and forget about them. This log and forget approach builds up a trail of execution as your program runs. If you run into problems at a later stage in development you may already have a considerable amount of information (gleaned from the trail your software left as it executed) available leading up to the point of failure.
Logging provides more information
Logging can provide much more information than just exceptions or stack traces because you are not so much worried about the noise of too much output like you would be if you were just printing your messages to screen. This allows you to log more information about the actual running state of your program.
You might log when you enter certain sections of code and when you leave them, you might log points of abnormal behavior, exception stacks and any other information that you think might be useful as a trail later on. If you encounter a severe error in your program that causes it to crash, you have both pre-crash information as well as stack trace information associated with the crash. Having both of these pieces of information together is significantly better than having just one or the other.
A stack trace on its own for example tells you the type of problem that occurred, but it doesn’t necessarily tell you why the program crashed. What behavior occurred prior to the crash? What state were certain objects in prior to the crash? This extra information can really help put a crash into context leading to a quicker resolution.
Logging yields increased message control
Unlike printing to a standard output stream like the screen which is either on or off, you can customize your logging messages with varying degrees of granularity. Most logging packages give the ability to log messages at a particular level; on, off, all, info, fine, finer, finest for example. This gives you the flexibility of quickly turning all logging information on or off, just looking at messages logged as information (general program flow and behavior for example), whilst classifying debugging information at varying degrees of granularity.
This gives you the control to switch off finer debugging information when it is not needed but ensures this information is still available when you do need it. This sort of flexibility just isn’t available when printing straight to standard output; be it screen, file or otherwise.
Logging extends to maintenance use
In most cases you will not want all the debugging information you output to the console during debugging to appear to users of your software as the program runs or crashes. To most users this information is not going to be meaningful and even to those that it is, they cannot do anything about it unless they have a copy of the source code.
This is where log files come in handy. They can be discrete, created silently in an unobtrusive way that the user is not aware of. Some companies setup an automatic log file submission when a crash occurs in their software allowing any log information generated to be forwarded to the developers for inspection. This gives the developers plenty of information about the problem but in many cases also the operating environment in which the problem occurred. This is important because abnormal behavior might only exist on a certain set of hardware. Tracking this sort of problem down can be quite difficult if not impossible if this sort of information is not present.
So the benefits to incorporating logging in your software are four fold;
An increase in debugging efficiency through the practice of log it and forget it
Increased information availability
Increased message control and handling
After production information availability
Next time you develop a piece of software that does not have logging. Think about these benefits and also the amount of time you spend in debugging. Even with a simple practice like value or statement debugging via standard output. There’s a good chance a solid logging practice will benefit your pre and post production development.
Joshua Hayes
codelines.net.au Software design and development for passionate people
Software Developer