Debug Levels

Question

Hi, I would like to know if you guys have any suggestions about debug levels when writing an application. I thought about 4 levels: 0 : No Debug 1 : All inputs and outputs 2 : "I am here" notification from significant functions with main parameters 3 : All variables verbose

Thanks,

Omri.

Answer 1

Whatever you choose, there will be something you wanted to see which is just into the next level...

I don't think there is a general answer to this question, because it's so dependent on what the application is doing. Much like the oily pages in the Haynes manual (UK readers will know what I mean), I tend to find that you end up with heavy logging in the areas which have traditionally been troublesome, and almost none in the area which is going to cause you trouble next.

Answer 2

This is my list:

• Silent-Mode:

Application emits nothing debug-related. Under no circumstances the application will emit anything to the UART or debug-console.

• Error-Mode:

Hard and un-recoverable errors are logged to the console.

• Warning-Mode:

Enables extra debug-information intended to help other programmers.

This mode is not intended to catch bugs but to provide information to other programmers who use my applications/library. In warning mode I mostly check the input parameters and try to detect if someone tries to do something stupid. Like brute-force a solution or passing just the data-type that's slowest around.

• Debug-Mode (Level 1-4)

In Debug mode I start to log everything, sorted by frequency of occurance. Level one is not very verbose. Major things that my program/application has done gets logged. Not much more. This mode is intended to be used to get a rough idea of what a client is doing.

The higher the debug-mode, the more information gets logged.

My highest level of debug is reserved for all interprocess and interthread communication. All accesses to semaphores, mutexes ect will be logged with as much detail as possible.

Answer 3

Here's what we did in one project I worked on. It's not the bible of logging levels, just one possibility. Logging should be fitted to your situation.

• LOG_SEVERE, severe errors that require program exit (e.g., in an application, you ran out of disk space).
• LOG_ERROR, error messages that can't be recovered from but the program can continue to run (e.g., in a server application, client sent through bad data but other clients can continue to run).
• LOG_WARNING, recoverable problem that you should be notified about (e.g., invalid value in a configuration file, so you fell back to the default).
• LOG_INFO, informational messages.
• LOG_ENTRY, log entry and exit to all functions.
• LOG_PARM, log entry and exit to all functions with parameters passed and values returned (including global effects if any).
• LOG_DEBUG, general debugging messages, basically useful information that can be output on a single line.
• LOG_HIDEBUG, far more detailed debugging messages such as hex dumps of buffers.

Each level also logged messages in 'lower' levels. There was sometimes a question as to whether a debug message should be LOG_DEBUG or LOG_HIDEBUG but we mostly based it on the number of lines it would push out to the log file.

Answer 4

What is really most important with different levels of logging is that all developers are using the same definitions.

I've seen examples of developers logging an Error from a tcp package when failing to deliver a packet even though that is handled and a resend is done by the caller.
The developer in question said: "But in this context, it's an error".

You need to define things like:
An error means that the application has failed and needs to be restarted.
A warning may meen that a single function of the application has failed but that the application can recover and continue
and so on...

The exact number of levels isn't at as important as the consistent use of those levels throughout the application.

It can be very helpful if it's possible to change levels during runtime and if possible select different levels for different parts of the application.

Answer 5

I indented to separate the debug logs from the audit logs and exception logs. so logs who are informatic like for example the function SendMessage that finished successfully or not will be audit logs, but logs of any failure of the application to send that message who caused an exception will be exception logs.

Debug logs are intended to be used for debugging purposes only. the levels are for me to choose how severe the debugging will be.

I think that for developers that work in a group its important to set these rules before even starting to code.. so the logging will be consist.

Thanks for the good suggestions!

Omri.

Answer 6

I have:

• Critical/Fatal, the program can't possible continue, normally the user lost it.
• Error, someting really wrong, used data can be corrupt, but you can be lucky.
• Warning, this is not right, I can continue, but please have a look.
• Hint/Information, i like to say something, but I don't expect you to listen.
• Debug, all information only interesting for programmers.

Normaly the lowest two levels are blocked. But the others are shown. And if you want to block the Fatal level, its fine with me, but don't expect that I clean up the mess afterwards (unfortunately I still have to...).

Answer 7

0: no logging

1: exception logging: log every thrown error. For example in c#: logging in catch blocks. When these log operations are triggered, you know you have an error. You can also log in switch statements if there is a case which should never be hit and the like.

2: operation logging: logging operations, which are not in catch blocks (normal operations), should be set to high debugging. This way you can see which method starts executing and then ends up in a catch block.

Also, think about logging switches, for example packet logging (true: log network packets/messages, false: don't). Just don't overdo with switches.

At exception handling, every method body should be at least in a try-catch block, at least with a general Exception catch at the end. Put logging in the catch block, add optional information besides the system message and the stack trace to indicate what caused the error, then throw the error. Stop throwing errors further only when the user has been notified about the error, or you are at the top level of an application, which has no active user interface. (Server side logging for example.) Then you need to indicate in a message to the client app that an error has happened server side.

Answer 8

I have normally used more than just four levels, though they don't necessarily have names. You might look at the levels provided by the 'syslog' daemon process.

0 - Emergency (emerg)
1 - Alerts (alert)
2 - Critical (crit)
3 - Errors (err)
4 - Warnings (warn)
5 - Notification (notice)
6 - Information (info)
7 - Debug (debug)

These are not directly relevant, but should give you some pause for thought. The list provided by Pax is pretty reasonable.

One thing that I've often found useful is segmentation of the debugging - different levels of debugging settable for different components of the system. For example, depending on where the trouble is, I might need heavy debugging in the input section and macro management section, while not needing any debugging in the main processing code. A single debugging level across the whole program is considerably better than nothing, but for complex programs, differentiation is invaluable.

Yes, I have source code that I use - contact me (first dot last at gmail dot com) if you want a copy.