Chapter 17

Error Handling and Debugging

Writing a piece of software, even a relatively small one, can be an extremely complicated task. Developers usually put careful forethought and planning into the nature of the task and the means they will use to solve the task through the program that they intend to write.

The complex nature of software development invariably leads to errors in programming. This chapter sets out to explain the different types of errors that you might encounter when writing Visual Basic .NET code, some of the tools that you can use to locate these errors, and the coding structures used to prevent these errors when users run your program.

In addition to programming errors, your application should be able to gracefully handle all the abnormal conditions it may encounter, from user errors (when they enter a string where the program expects a date or numeric value) to malfunctioning devices, or simpler situations such as not being able to save data to a file because another application is using it. All these conditions may be beyond your program’s control, but your application should be to handle them. At the very least, your program shouldn’t crash; it’s OK to abort an operation and display a warning, but an application shouldn’t crash.

Types of Errors

The errors caused by a computer program (regardless of the language in which the program is written) can be categorized into three major groups: design-time, runtime, and logic.

The design-time error is the easiest to find and fix. A design-time error occurs when you write a piece of code that does not conform to the rules of the language in which you’re writing. They are easy to find because Visual Studio .NET tells you not only where they are, but also what part of the line it doesn’t understand.

Runtime errors are harder to locate, because VS doesn’t give you any help in finding the error until it occurs in your program. These errors occur when your program attempts something illegal, like accessing data that doesn’t exist or a resource to which it doesn’t have the proper permissions. These types of errors can cause your program to crash, or hang, unless they are handled properly.

The third type of error, the logic error, is often the most insidious type to locate, because it may not manifest itself as a problem in the program at all. A program with a logic error simply

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

792 Chapter 17 ERROR HANDLING AND DEBUGGING

means that the output or operation of your program is not exactly as you intended it. It could be as simple as an incorrect calculation or having a menu option enabled when you wanted it disabled, or something complex like a database that’s duplicating order information.

This section will cover and demonstrate all three types of errors, and show you tools and techniques that you can use to hunt them down and squash them.

Design-Time Errors

Also called syntax errors, design-time errors occur when the Visual Basic .NET interpreter cannot recognize one or more lines of code that you have written. Some design-time errors are simply typographical errors, where you have mistyped a keyword. Others are the result of missing items: undeclared or untyped variables, classes not yet imported, incorrect parameter lists in a function or method call, or referencing members of a class that do not exist.

A program with as few as one design-time error cannot be compiled and run—you must locate and correct the error before continuing. Fortunately, design-time errors are the easiest to detect and correct, because VB.NET shows you the exact location of these errors and gives you good information about what part of the code it can’t understand. What follows is a brief example showing several design-time errors in just a few lines of code.

The event code shown in Figure 17.1 was typed into the Click event of a button named Button1.

Figure 17.1

VB.NET identifies the locations of design-time errors.

Note the three blue squiggly lines under various parts of this brief code (under two instances of the letter i and under the term lbNumbers). Each one of those squiggly lines represents a design-time error. To determine what the errors are, locate the Task List window in the IDE and bring it forward. The Task List displays the errors seen in Figure 17.2 for the code from Figure 17.1.

Figure 17.2

Corresponding errors in the Task List

Note You can determine which squiggly blue line corresponds to which design-time error in the Task List by doubleclicking the error in the Task List. The corresponding error will become selected in the code window.

Note that two of the errors are the same: they state “The name ‘i’ is not declared.” In this case, these errors are telling you that you’ve referenced a variable named i but you have not declared it. To fix these two errors, you need to modify the code as shown in Figure 17.3.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

TYPES OF ERRORS 793

Figure 17.3

Once declared, the variable doesn’t produce an error.

The only error remaining now is “The name ‘lbNumbers’ is not declared.” As the programmer of the application, you would probably have some type of idea what lbNumbers is. In this case, I was attempting to add 100 items to a ListBox, and lbNumbers is supposed to be the name of the ListBox on the form. This error tells me that I do not have a ListBox on the form named lbNumbers. I’ve either forgotten to put a ListBox on the form entirely, or I did add one but did not name it lbNumbers. To correct the problem, I can either make sure a ListBox is on my form with the correct name, or I can change this code so that the name matches whatever I’ve named the ListBox.

I added a ListBox named lbNumbers to my form. After doing so, however, I’m still left with a syntax error on the line, as seen in Figure 17.4.

Figure 17.4

The ListBox statement still produces a design-time error.

Note that the text of the error is different. It reads “The name ‘add’ is not a member of ‘System

.Windows.Forms.ListBox’.” This is telling you that it now recognizes that lbNumbers is a ListBox object, but there is no member (property, event, or method) named add on a ListBox. So what’s the correct way to write a line of code that adds an item to a ListBox? Some brief research in the help should yield the correct line of code—the one shown in Figure 17.5.

Figure 17.5

This syntax is correct.

Notice that all blue squiggly lines are now gone, and the Task List should be empty of errors as well. This means our program is free of syntax errors and is ready to run.

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

794 Chapter 17 ERROR HANDLING AND DEBUGGING

Runtime Errors

Runtime errors are much more insidious to find and fix than design-time errors. Runtime errors are problems encountered by your program while it’s running. Runtime errors can take on dozens of different shapes and forms. Here are some examples:

Attempting to open a file that doesn’t exist

Trying to log in to a server with an incorrect username or password

Trying to access a folder for which you have insufficient rights

Requesting data from a database table that has been renamed

Opening a file on a server that is down for maintenance

Accessing an Internet URL that no longer exists

Allocating a resource without the necessary available RAM

Dividing a number by zero

Users entering character data where a number is expected (and vice versa)

As you can see, runtime errors can occur due to an unexpected state of the computer or network upon which your program is running, or simply because the user has supplied the wrong information (an invalid password, a bad filename, and so on). Because of this, you can write a program that runs fine on your own machine, and all the machines in your test environment, but fails on a customer site due to the state of that customer’s computing resources.

As you might imagine, runtime errors can be many degrees harder to diagnose and fix in comparison to design-time errors. After all, any error you make in design time is right there in front of you, on your own development PC. Not only that, but the Visual Studio compiler goes ahead and tells you right where a design-time error is and why it’s an error. The runtime error, by comparison, may only manifest itself in strange computing conditions on a PC halfway across the world. We’ll see in later sections how runtime errors can be detected and managed.

Logic Errors

Logic errors also occur at runtime, and because of this, they are often difficult to track down. A logic error occurs when a program does not do what the developer intended it to do. For example, you might provide the code to add a customer to a customer list, but when the end user runs the program and adds a new customer, the customer is not there. The error might lie in the code that adds the customer to the database; or perhaps the customer is indeed being added, but the grid that lists all the customers is not being refreshed after the add customer code, so it merely appears that the customer wasn’t added.

A second example of a logic error: suppose you allow the end user to manually type the twoletter state code of every customer address that they enter into your program. One of the functions of your program might be to display a map of the U.S. that shades the states based on the number of customers within each state. How do you suppose your shaded map will display customers with invalid state codes? Most likely, these customers would not be displayed on the map at all. Later,

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com

TYPES OF ERRORS 795

the manager of the department calls you and says “The Total Customers Entered report for last month tells me that 7,245 customers were entered into our system. However, the Density Map report only shown 6,270 customers on it. Why don’t these two reports match?”

In this example, we’ve made a design decision—the decision to allow the end user to type the two-digit state code—and that decision has lead to a major logic error, the fact that two reports from the same system give different results for the number of customers entered into the system for the same time period.

Here are some actual VB.NET code snippets that produce logic errors. Consider the following code snippet.

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

ByVal e As System.EventArgs) Handles Button1.Click Dim i As Integer

i = 1

Do While i > 0 i += 1

Loop End Sub

Here we have an integer variable set to 1 and incremented by one in a loop. Each time the loop iterates, the number gets bigger. The loop will continue to iterate as long as the variable is greater than 0. See any problem with this? The problem is that the value of the variable will always be greater than 0, so the loop will never terminate. This is called an infinite loop, and it’s one of my personal favorite types of errors (favorite in the sense that I seem to always find a way to write new and exciting flavors of infinite loop). Of course, this loop isn’t exactly infinite—after 2 billion iterations, an overflow will occur, but that’s a good indication as to what happened.

Here’s another simple example of a logic error:

Private Sub ColorTheLabel(ByVal lbl As Label) If CInt(lbl.Text) < 0 Then

lbl.ForeColor = Color.Green Else

lbl.ForeColor = Color.Red End If

End Sub

This routine was intended to color the text of a label red if the label text contained a negative number, and green if it contained a positive number (or 0). However, I got the logic backward— the label text is green for numbers less than 0, and red otherwise. This code won’t produce any design-time errors or runtime crashes. It simply does the opposite of what I intended it to do.

Note finally that logic errors may or may not manifest themselves as program crashes. In the logic error examples above, the programs wouldn’t have crashed or produce any type of error message— they simply did not perform as intended. Some logic errors might indeed produce a program crash, at which point the line between a logic error and a runtime error becomes blurry. The fact that a new customer doesn’t appear in a grid might cause a crash if your program tries to highlight that new customer in the grid but the customer row isn’t there. In this case, we’ve made a logic error (not adding the customer to the grid) that’s caused a runtime error (program crashes when it tries to

Copyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com