DEBUGGING 803

This code is taken from a ProgressBar control. It is the code that implements the Value property of the ProgressBar control. A check is done to make sure that the value that the property is set to is less than or equal to the value of the Max property, since you can’t set the current value to be bigger than the maximum defined value. If the property is trying to be set to a value larger than the max, then an exception is generated via the Throw statement. This statement instantiates an exception of class OverflowException and produces a custom error that the fellow developer can see in his own exception handler.

Debugging

As you’ve seen, encountering errors is nearly a certainty when developing a piece of software. Syntax errors, of course, are the easiest to detect, because the IDE tells you right where they are and what the nature of the error is. It’s the runtime errors that are harder to locate and correct, because of the many forms these errors can take. You’ve seen examples of errors that will cause your program to crash, as well as errors that spiral your program off into an infinite loop, and even errors that produce no outward signs at all—they simply cause the program to behave in some unintended way.

Fortunately, Visual Studio .NET provides you with a fine selection of tools to detect and remove the errors in your program. The act of hunting and eliminating errors is called debugging, because you’re goal is to remove the bugs (or de-bug) the program.

Breakpoints

The breakpoint is the first and most important weapon in the war against bugs. When you set a breakpoint in your program, you’re telling VS.NET to stop execution of the program when it reaches a certain line in the code. Once stopped, you can examine the state of the program, including the values of the variables, the procedure stack, and the contents of memory.

Before we can look at debugging essentials, we need some buggy code. Let’s write a program to count all the vowels in a string. To set this program up, start a new WinForms project, then add a button named cbCount and a TextBox named tbPhrase to the form. Add the code from Listing 17.9 to the project.

Listing 17.9: Bug-Filled Code

Private Sub cbCount_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles cbCount.Click cbCount.Text = CountTheVowels(cbCount.Text)

End Sub

Private Function CountTheVowels(ByVal cSomeString As String) As Integer Dim x As Integer = 1

Dim iTot As Integer = 0 Dim iPos As Integer

Do While x <= cSomeString.Length

iPos = InStr(“aeio”, cSomeString.Substring(x, 1).ToLower) If iPos > 0 Then

iTot += 1

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

804 Chapter 17 ERROR HANDLING AND DEBUGGING

End If

Loop

Return iTot

End Function

The button click event passes the contents of the text box into the function CountTheVowels(), which is where all the dirty work will be performed. When the count is obtained, the caption of the button should be replaced with the vowel count. Once you get the code for the program typed in exactly as seen above, try running the program, entering some text into the text box, and clicking the button. Then wait. And wait. My guess is that the caption of the button will not change until you stop the application by pressing Ctrl+Break (or select Debug Stop Debugging). If you wait long enough, an overflow exception will occur. This means that the value of the variable iTot has exceeded the maximum value you can represent with an Integer.

Obviously, this little function shouldn’t take very long to run, so something screwy must be going on, like an infinite loop. Let’s set a breakpoint in the function and see if we can spot it.

To set a breakpoint, place the cursor on a line of code in the function where you want the program to stop, and press the F9 key. The line of code should become highlighted in red, as seen in Figure 17.9.

Figure 17.9

Setting a breakpoint

Once a breakpoint is set, you can begin the program, type some text into the text box, and click the button. Like a good soldier, the debugger should come up on that same line of code, this time highlighted in yellow. This means that the program has stopped execution on that exact line of code.

Now we can start looking around. First, take the cursor and hover it over some of the areas of code. You should be able to see a tooltip displaying the value of the various variables you rest the mouse over, like the one in Figure 17.10.

Figure 17.10

Tooltips display the value of variables.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

DEBUGGING 805

The figure displays the first of the errors I’ve made coding this program. The value of the variable cSomeString is “Count Vowels”, but this is not the string I typed into my text box. Why is this string being passed into the function? A quick examination of the function call reveals this problem.

cbCount.Text = CountTheVowels(cbCount.Text)

Note that I inadvertently passed the Text property of the button cbCount, when my intention was to pass in the value of tbPhrase.Text. This is a perfect example of a logic error. The code works fine (well, anyway, it will work fine once we find the rest of these bugs), but it won’t count the vowels in the string that we intended to count. The fix for this first bug is easy. First, stop the program from running by selecting Stop Debugging from the Debug menu (shortcut key is Shift+F5).

Note Spend some time memorizing the shortcut keys for all the debugging functions. You’ll be make using these functions quite a bit, and use of the shortcut keys will save a ton of time.

Once the program is stopped, change the CountTheVowels() function call as follows (note the change marked in bold font). Now we’re passing in the string we intended.

cbCount.Text = CountTheVowels(tbPhrase.Text)

Stepping Through

As it often happens, we started looking for an infinite loop but found another, unrelated bug first. Now that we’ve squashed that bug, we can go back to running the program and looking for the original problem. Start up the program again, type some text into the text box, and click the button. Once again, the program should stop at the breakpoint.

Let’s watch a few of the program lines run in sequence and see if that tells us anything. To make the program step through the current line of code, press the F10 key. Each time you press F10, one line of code will execute, and the yellow highlight will move to the next line of code that is about to be executed.

Note The F11 key also steps through the code, but it will step into any procedures that are called. The F10 key steps over the procedure calls, running them all at once and returning back to the original spot. This allows you to skip over the line-by-line tracing of procedures that you are not currently debugging.

You can continue to trace through the loop line by line and examine variable values with the tooltips. Can you figure out the cause of the infinite loop? Perhaps it’s time to bring in some more debugging tools.

The Local and Watch Windows

While still stopped in debug mode, select Debug Windows Locals from the menu. The Locals window (Figure 17.11) should be displayed in the lower section of the IDE. This window shows you the current value of all of the locally declared variables. Now we can see the value of the variables changing as we step through the program.

Try stepping through the loop a few more times. What you might notice is that the values of the variables aren’t changing. To get even more information, highlight the entire phrase cSomeString

.Substring(x, 1).ToLower, right-click, and select Add Watch from the context menu. This will bring up the Watch window, as seen in Figure 17.12.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

806 Chapter 17 ERROR HANDLING AND DEBUGGING

Figure 17.11

The Locals window

Figure 17.12

The Watch window

The Watch window is similar to the Locals window, but it allows you to look at the value of complex expressions like the one we just placed in it. Once again, try stepping through the loop a few times. You might expect that the Substring command would be incrementing the letter in the string as the loop iterates, but that isn’t happening. The only logical reason for this is that the value of counter variable x isn’t changing. Let’s look at the loop again.

Do While x <= cSomeString.Length

iPos = InStr(“aeio”, cSomeString.Substring(x, 1).ToLower) If iPos > 0 Then

iTot += 1 End If

Loop

I’ve made one of the classic looping blunders here. I set up a counter variable x to loop through the string character by character, but I never added any code to increment the string! That’s as sure a recipe for an infinite loop as anything. Fixing that problem is an easy remedy (see the code highlighted in bold).

Do While x <= cSomeString.Length

iPos = InStr(“aeio”, cSomeString.Substring(x, 1).ToLower) If iPos > 0 Then

iTot += 1 End If

x += 1

Loop

Okay, that bug is squashed, so it’s time to remove the breakpoint and rerun the program to see if it works. This time, however, the program crashes and burns with the following error.

An unhandled exception of type ‘System.ArgumentOutOfRangeException’ occurred in mscorlib.dll. Additional information: Index and length must refer to a location within the string.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

DEBUGGING 807

We’ve seen that error before—it means that we tried to look at a character beyond the length of the string. By checking the Locals window, you should be able to eventually track down this problem. The problem here is that the loop counter x starts at character 1 and ends at value cSomeString

.Length. While that range is correct for VB version 6 and below, .NET strings are indexed starting at 0. Oops. We need to modify our procedure as shown by the two bold items here, the zero and the lessthan sign:

Private Function CountTheVowels(ByVal cSomeString As String) As Integer Dim x As Integer = 0

Dim iTot As Integer = 0 Dim iPos As Integer

Do While x < cSomeString.Length

iPos = InStr(“aeio”, cSomeString.Substring(x, 1).ToLower) If iPos > 0 Then

iTot += 1 End If

x += 1 Loop Return iTot

End Function

This modified loop starts at 0 and ends at cSomeString.Length - 1, which is the correct way to iterate through a .NET string. Once again, you can try to remove all breakpoints and rerun the application. This time, it should actually produce a value, like the successful test in Figure 17.13.

Figure 17.13

We’ve debugged our program … or have we?

Finally, we got an answer! But is it the correct answer? A manual count gives 11 vowels in the test string “The quick brown fox jumps over the lazy dog”. Since this is a fairly long test string, you might want to try a smaller string, like the string “aeiou” shown in Figure 17.14.

Now that’s definitely wrong—it’s counted only four of the five vowels in the string. Looks like there’s another logic error. Back to the debugging drawing board … Actually, this error is pretty easy compared with some of the others we’ve already squashed. Look at the actual comparison of the character to the vowel list.

iPos = InStr(“aeio”, cSomeString.Substring(x, 1).ToLower)

Where’s the u? It looks like I simply forgot to include the u in the vowel list. After adding the u back in, the final, working code looks like Listing 17.10.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

808 Chapter 17 ERROR HANDLING AND DEBUGGING

Figure 17.14

It’s clear that a mistake occurred.

Listing 17.10: Bug-Free Code

Private Sub cbCount_Click(ByVal sender As System.Object, _

ByVal e As System.EventArgs) Handles cbCount.Click cbCount.Text = CountTheVowels(tbPhrase.Text)

End Sub

Private Function CountTheVowels(ByVal cSomeString As String) As Integer Dim x As Integer = 0

Dim iTot As Integer = 0 Dim iPos As Integer

Do While x < cSomeString.Length

iPos = InStr(“aeiou”, cSomeString.Substring(x, 1).ToLower) If iPos > 0 Then

iTot += 1 End If

x += 1 Loop Return iTot

End Function

This is the type of error you can only catch with exhaustive tests—that is, only a user will likely catch this error. You can actually test the program with a string that doesn’t contain the character “u,” see that it works nicely, and distribute it. Very soon you will receive messages to the effect that your application doesn’t work. Yet this application has been tested and seems to work fine. The tests, however, were not exhaustive.

You should also try to test your applications with extreme situations (a blank string, for example, or a very large one, an invalid numeric value, and so on). The final test, of course, is to pass the applications to users and ask for their comments. Unfortunately, we don’t write software for each other. We write software for people knowledgeable enough to crash an application in minutes but not knowledgeable enough to keep it running.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com