In my current developement, I have decided to keep the command prompt open so I can see debug messages. For example, if something wasn't happening when it should, I would put a cout statement at every function to determine where the broken link is. Sometimes, I might get hundreds of the same message (like WM_MOUSEMOVE) and I need to determine whether or not the messages are still coming, so I would using a static variable, and increment it, so I might have:

3> WM_MOUSEMOVE processed.
4> WM_MOUSEMOVE processed.
54> WM_CLICK processed.
5> WM_MOUSEMOVE processed.

in my cmd. (Don't ask me why there would be 54 WM_CLICK and 4 WM_MOUSEMOVE)

What I would like to know is your opinion. Is this a good approach to debugging? What kind of syntax would you use for consistency? Does a syntax even matter? And would you make any suggestions to how this method could be improved.

4 Answers 4


There are a few ways.

What you are using is a rudimentary form of logging. It's probably the most time-efficient way of debugging most errors. It's worth your time to write a solid logging module that can be redirected to screen or file, buffered/unbuffered, etc. It should have a timestamp and a message, if nothing else.

There is also throwing exceptions - this can be more useful with languages that perform a stack trace using symbols, e.g., Java or Python. Perl can croak() or die() with similarly useful information.

One other method is having a large array of unit tests which can pick up errors in a refined fashion. That of course implies well-written tests.

The above are essentially non-interactive methods.

There is also Ye Old Interactive Debugger, which functions in various levels of usefulness depending on development environment. Lisp probably has the best debugging facilities available; C# probably has the most developed UI. Interactive debuggers can be very useful when your code "logically" should work, and you really need to do some serious variable-ogling and probe around. It's probably the most inefficient and hard to replicate of all the methods, but can be really useful.

The interactive debugger can be extended to have various conditions and scripts run on variables hitting values, but I'm not sure if any current environments support it - the last one I heard of was developed in '93 for... Prolog? Can't recall off the top of my head.

One method that was researched in the early 80s and is having a minor comeback today is replayable/reverse debugging. I am working on doing that in my thesis for a highly exotic embedded system.

  • I'll add Smalltalk's debugging facilities as a peer of Lisp's. Nothing quite like hacking on a currently executing piece of code, both for fixing stuff as well as for exploring the code. Oct 9, 2010 at 6:46
  • @Frank: I haven't explored Smalltalk really. Does it have a full-featured development environment runnable on a modern system? Oct 9, 2010 at 6:52
  • Absolutely! Squeak runs on Linux, Windows, OS X and a bunch of other platforms. It has an interactive debugger, code browsers and oodles of tools. Oct 9, 2010 at 7:01
  • It is even better to use a solid logging module written by others instead of developing one yourself.
    – user1249
    Feb 15, 2011 at 19:45

You are slowly but surely reinventing the "logger" concept, where the three inventions you need are:

  • A seriousness indication of the message. Is this trivial debug information or a notification that the disk system is corrupted?
  • The ability to skip messages you are not interested in.
  • A need for a message to go somewhere else than on your console.

Others have done the same before you and honed and polished the idea until they got a framework allowing you to say things like:

} catch (Exception e) {
  log.error("Subsystem X threw exception!", e);

The logger subsystem then decides if this message should be logged at all, where it needs to go, as well as collects the exception thrown so it can go with the message. It might be saved for later in a text file, sent as an email or notified in your favorite instant messenger. This can be very useful for analyzing problems after they happened.

I wrote an introduction to how to start using logging in Java, which you might find interesting, regardless of what language you happen to use. See http://runjva.appspot.com/logging101/index.html


Sometimes cout statements are easier to do, but I think exceptions are the way to go in most cases.

  • I rarely use exceptions for the express intent of debugging - but then, debugging to me means adding often temporary code to check why something doesn't work the way it should. Uncaught exceptions in a good debugger do give a lot of information, so they are certainly useful though.
    – Lizzan
    Oct 9, 2010 at 12:04

I use couts/traces all the time - I find that breakpoint style debugging often interrupt my thought process too much and make it more difficult to actually follow the execution. At times, however, breakpoint debugging is absolutely invaluable. I think it's important to be familiar with several styles of debugging and choose the best for each case - breakpointing a mouse move would be hell, for one thing...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.