Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

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.

share|improve this answer
    
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. –  Frank Shearar Oct 9 '10 at 6:46
    
@Frank: I haven't explored Smalltalk really. Does it have a full-featured development environment runnable on a modern system? –  Paul Nathan Oct 9 '10 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. –  Frank Shearar Oct 9 '10 at 7:01
    
It is even better to use a solid logging module written by others instead of developing one yourself. –  user1249 Feb 15 '11 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

share|improve this answer

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

share|improve this answer
    
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 '10 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...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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