Were you taught debugging

[GCDEF]

This list is pure nonsense.

For example why is a debugger better than the rest?

All the methods you suggested
Debugger
Log File
Event log
Trace output
Message box

with the exception of the debugger, require you to modify your code specifically for the purpose of debugging. That in itself aside from being messy and time consuming can alter the behavior of the program.

Among other things., the debugger lets you watch your program run step by step. It lets you view and jump around in the call stack and examine the local variables at any point in the stack. It lets you watch variable assignments as they occur in real time or even change the value of variables while the program is running. It lets you see return values from functions and values of arguments passed into functions. It lets you watch variables or memory locations and break when they change. It lets you modify your code and continue execution right where you left off.

[ninja9578]

When I use logging, I prefer a logging mechanism that is capable of different log levels and has indenting. With this logging framework, I generally log when I enter and leave method (usually logging additional info in these calls as well). I just find it easier to read the log file that clearly shows where you've entered and exited methods as opposed to a left-aligned log.

I do the same thing. I declare a global variable that tells the logger how much to indent and I alter it as needed.

[dc_2000]

Log File ... require(s) you to modify your code specifically for the purpose of debugging. That in itself aside from being messy and time consuming can alter the behavior of the program.

You normally do it like this:

//On a global scale
#define DO_LOG_MY_EVENTS   //Comment this line if logging is not necessary

#ifdef DO_LOG_MY_EVENTS
     #define LOG_MY_EVENT(a, b, c) LogMyEvent(a, b, c)
#else
     #define LOG_MY_EVENT(a, b, c) 
#endif

//And then when you need to log an event:
LOG_MY_EVENT(__LINE__, __FILE__, _T("Whatever else"));

In most cases it will not interfere with the original flow of the code.

I do the same thing. I declare a global variable that tells the logger how much to indent and I alter it as needed.

Declaring any global variables would not be good in case of multi-threading.


Question to all of you, do you use Windows built-in event logging, or something that you came up with yourself?

[Arjay]

I've found as time goes on, the logging frameworks become more sophisticated. I prefer a framework that has multiple output targets (Console, debug trace, logfile, event log, etc) and on that you can externally change settings such as what components to log, detail level and so on.

As far as what I use, I've used and use both built-in frameworks and homegrown ones.

[GCDEF]

You normally do it like this:

//On a global scale
#define DO_LOG_MY_EVENTS   //Comment this line if logging is not necessary

#ifdef DO_LOG_MY_EVENTS
     #define LOG_MY_EVENT(a, b, c) LogMyEvent(a, b, c)
#else
     #define LOG_MY_EVENT(a, b, c) 
#endif

//And then when you need to log an event:
LOG_MY_EVENT(__LINE__, __FILE__, _T("Whatever else"));

In most cases it will not interfere with the original flow of the code.

I don't see how that's better, cleaner, easier or more efficient or effective in any way shape or form than using the debugger. That looks like something I may have done 25 years ago when I didn't have an integrated debugger available.

[ninja9578]

You normally do it like this:

//On a global scale
#define DO_LOG_MY_EVENTS   //Comment this line if logging is not necessary

#ifdef DO_LOG_MY_EVENTS
     #define LOG_MY_EVENT(a, b, c) LogMyEvent(a, b, c)
#else
     #define LOG_MY_EVENT(a, b, c) 
#endif

//And then when you need to log an event:
LOG_MY_EVENT(__LINE__, __FILE__, _T("Whatever else"));

In most cases it will not interfere with the original flow of the code.

That's exactly what I do too, thank god for preprocessor

Declaring any global variables would not be good in case of multi-threading.

Agreed.

[Arjay]

Declaring any global variables would not be good in case of multi-threading.

Agreed.

It depends. If they are set at program startup and only read from that point on, then there's no problem. If they are changed during program operation and multiple threads are reading them, then there's a problem.

[ninja9578]

The thing that I hate the most is when the log alters the results of the execution. It usually only happens while multithreading, but I've been fighting a bug for the past 4 hours in a single threaded app where my log makes it run correctly, but turning the log off causes it to crash.

[Paul McKenzie]

The thing that I hate the most is when the log alters the results of the execution. It usually only happens while multithreading, but I've been fighting a bug for the past 4 hours in a single threaded app where my log makes it run correctly, but turning the log off causes it to crash.

Turning on the log can do that sometimes, regardless of whether it's a single thread or multi-threaded app.

I've had my share of those very same issues, where running with logging turned on makes everything "work". If it's a crash, the crash or core dump is a valuable piece of information.

Regards,

Paul McKenzie

[JohnW@Wessex]

I prefer a framework that has multiple output targets (Console, debug trace, logfile, event log, etc) and on that you can externally change settings such as what components to log, detail level and so on.

That's very much what our home grown one does too. There are four levels (Critical/Warning/Info/Debug) and four output channels (Win32 debug output/memory log/stream/console).
There can be many debug 'sections', each one identified by a unique string, usually based on the namespace & class name. Sections are enabled in a file. The code calls the Get_Log function to get a reference to its log, or a null log if not enabled.
As our code is often very time critical the log also contains a high resolution timestamp.

Having an external file is very important as we may want to turn options on & off out in the field. Uploading new versions of code with new debug options may not be contractually allowed.

[dc_2000]

Yeah, good point. What if at times you cannot debug a project? (Like when a bug happens in a module that is already in a customer's possession and you get a tech support message on par to this, "There's a glitch. Fix it!") Logs can be very useful in that case. How do you handle a situation like this, by the way?

Another application for log files could be tracking down the "race condition", when obviously a good ol' debugging won't cut it (well, unless you run it through a kernel debugger.) Good example where such may occur would be ending complex worker threads.

[JohnW@Wessex]

What if at times you cannot debug a project? (Like when a bug happens in a module that is already in a customer's possession

We have a small amount of debugging enabled by default in the config file. We would ask the customer to send us the log. If it didn't highlight the problem then we would either send them an updated config file and get them to try to replicate the bug or we would attempt to run our application in simulation mode with data logged from a real system.

[Rich2189]

I have a preferred list of debugging techiques.
Message box

It is not wise to use message boxes for printing results; in the unfortunate event you do get stuck in an infinite loop you're stuffed.

Most of us here will be good enough to avoid infinite loop situations but they do happen from time to time. Most of all it isn't a good technique to show new programmers.

The debug output windows is the way to go for such messages.

[Ayyubid]

why call it a bug?

"hey chris, this line is bugging me" -1940

[Rich2189]

why call it a bug?

"hey chris, this line is bugging me" -1940

This was in my college text book if I remember correctly.

The first actual case of a computer bug was caused by a moth which had died in a computer case.

http://www.worldwidewords.org/qa/qa-bug1.htm