What do you log in your desktop applications to improve stability?

Question

I've started using SmartInspect in my Delphi applications because my users were running into bugs/problems I couldn't reproduce on my machine. When I have a general idea of the problem I'll monitor the application in a few specific places to confirm what is or is not working.

When the bug doesn't have an obvious cause, I feel lost. I don't know where to start logging in order to narrow down the problem. Are there common techniques or best practices for using a logger?

SmartInspect seems to be quite powerful, but I don't know quite what to log or how to organise my logs so the data is meaningful and useful for catching bugs.

NOTE: I'm using SmartInspect but I assume the answers should be suitable for any logging package.

Answer 1

Here are some guidelines I tried to implement in my own OpenSource logging unit, but it's fairly generic, and as you state, it should be suitable for any logging package:

• Make several levels (we use sets) of logging, to tune the logging information needed;
• Log all exceptions, even the handled one with a try...except block - and add an exception classes list not worth logging (e.g. EConvertError) - e.g. our unit is able to log all exceptions via a global exception "hook" (no try..except to add in your code), and handle a list of exception classes to be ignored;
• Log all "fatal" errors, like database connection issues, or wrong SQL syntax - should be done though "log all exceptions" previous item;
• For such exceptions, log the stack trace to know about the calling context;
• Be able to log all SQL statements, or database access;
• Add a generic User Interface logging, to know which main functions of the software the User did trigger (e.g. for every toolbar button or menu items): it's very common that the user said 'I have this on my screen/report, but I didn't do anything'... and when you see the log, you will discover that the "anything" was done. ;)
• Monitor the main methods of your application, and associated parameters;
• Logging is an evolving feature: use those general rules above, then tune your logging from experiment, according to your debugging needs.

Answer 2

For UI-driven applications here are the main things I instrument first:

1. ActionManager or ActionList's events when an action executes (gives me a user clicked here then here then here list).

2. Unhandled Exceptions with tracebacks using JCL debug go right in my main log, whereas if I was using MadExcept or EurekaLog, exceptions have their own log.

3. Background thread starts, stops and significant history events

4. Warnings, errors, API function failures, file access failures, handled (caught) exceptions.

Answer 3

Current memory usage can be useful for long running processes to see if there are memory leaks (which could lead to an out of memory error some day).