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.