Debugging your program

After creating your programs, it would be surprising if you had never had a bug in the code you've been writing. By now you should have written some original code for yourself, not just the examples supplied with the lessons. Whenever you write code there is the possibility of making mistakes. Heck! Even Professors make them, although very rarely. It can be very frustrating to try to find an error when you don't know where to begin to look. But there are techniques that can help.

Do you know where the term "bug", for a program error, comes from? In case you've never heard the story before, here it is, as told by Grace Hopper, one of the pioneers of programming.
In the late 40's even a simple computer was a big thing: 1000's of vacuum tubes and 1000's of square feet of floor space. A group of programmers were working late one hot summer night. To help to dissipate all the heat generated by those tubes, all the windows were open. At one point the program that they were working on bombed-out. Eventually they found the problem: a moth had flown in and had become lodged in the wiring, creating a short-circuit. Afterwards, every time a program would crash the programmer would exclaim, "There must be a bug in the machine!” To this day that has remained one of the mainstays of programmers: when the program goes wrong, blame the hardware!

One of the first techniques to master is the use of breakpoints. A breakpoint is a flag at a given point in code where program execution will be suspended to give you time to look at the content of variables or at the status of properties. When VB hits a breakpoint when running a program, the code window opens and an immediate window opens at the bottom of the screen. You can look at variables or properties in the immediate window and then, either do Start to resume execution or do Step, using to step through the execution, one statement at a time.

Again we will use the code from Lesson 5. In the code window, click the column to the left of a line of code. This will create a breakpoint indicated by a red dot (you remove the breakpoint by clicking on the red dot). When you run the program it will stop at the breakpoint. In the immediate window, look at the content of different variables or properties. Step through the code with ; the active statement is indicated by the yellow arrow. All the logic represented by IF or LOOP or DO statements will be executed according to the conditions present. If the yellow arrow jumps to a line that you don't expect, find the reason why.

Another technique to learn is called "error trapping". It consists in intercepting errors that can occur at execution rather than programming mistakes, although not providing for user errors can be considered a programming mistake.

Let's build a simple example. The user will input 2 numbers, a numerator and a denominator. The program will divide the numerator by the denominator and display the result. Easy so far. However, if the user inputs 0 for the denominator, the program crashes because programming cannot make sense of division by zero. So, we want to trap the error and process it before it displays an error message to the user. We will use the On Error GoTo ... statement. This tells the program that if there is some kind of run-time error, go to the error-processing-routine named. We have to create a line label to identify the error routine; a line label has a colon at the end, like error_rtn:, in the example. At the same time, there is an Err object created and it contains, among other things, a Number property that will identify the error. For example, if Err.Number = 11, the error was a division by zero; Err.Number = 6 represents an overflow situation.

It is worth noting that line labels in code do not end processing in any way. When the logic gets to a line label it keeps on going. The programmer has to make sure that the processing of errors in the error_rtn is not done automatically every cycle (that is called "falling through" the next routine and it's a common error).