Debugging versus Logging

Being first to the market with our XLr8Editor for Universe and Unidata, we were asked why we did not have a debugger.  Most of the time the answer was that you could not hookup to Universe's RAID debugger or Unidata's debugger without Telnet session and some type of changes to both products.  After Rocket Software's BDT came out with a debugger we looked at what they had done.  Rocket Software had changed both Universe and Unidata to talk to Eclipse.  Now our answer was that we needed access to the API they wrote for Eclipse.

In "The Practice of Programming" the authors Brian Kernighan and Rob Pike state: "As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient."

We have found the debugger certainly has its place but we are not Fan Boys.  Whenever a program has HTML, JavaScript, and UniBasic code, how can you figure out where the problem lies?  Maybe you are not even getting to your UniBasic code and your error is in the JavaScript.  That is why we use Firebug's console.log statement in JavaScript which just prints out a log to the console.  In our UniBasic code we call a logger throughout our code.  This logger subroutine writes out data to a file which we can use later to figure out where our problem is.

We always do say that logging has its problems.  It can slow down an application and calls to the logging subroutine are sometimes left in long after the problem is resolved.  However, we find that the process is much cleaner and we can look at the output long after the program has been run.