Finding and Correcting Errors

Finding and Correcting Errors

The defects you've encountered in your programs so far have probably been simple typing mistakes or syntax errors. But what if you discover a nastier problem in your program—one you can't find and correct by a simple review of the objects, properties, and statements you've used? The Visual Studio IDE contains several tools that help you track down and fix errors in your programs. These tools won't stop you from making mistakes, but they often ease the pain when you encounter one.

Three Types of Errors

Three types of errors can occur in a Visual Basic program: syntax errors, run-time errors, and logic errors.

• A syntax error (or compiler error) is a programming mistake (such as a misspelled property or keyword) that violates the rules of Visual Basic. Visual Basic points out several types of syntax errors in your programs while you type program statements and won't let you run a program until you fix each syntax error.

• A run-time error is a mistake that causes a program to stop unexpectedly during execution. Run-time errors occur when an outside event or an undiscovered syntax error forces a program to stop while it's running. For instance, if you misspell a file name when you use the System.Drawing.Image.FromFile method, or if you try to read the floppy drive and it doesn't contain a disk, your code will generate a run-time error.

• A logic error is a human error—a programming mistake that makes the program code produce the wrong results. Most debugging efforts are focused on tracking down logic errors introduced by the programmer.

If you encounter a syntax error, you often can solve the problem by using Visual Basic online Help to learn more about the error message, and you can fix the mistake by paying close attention to the exact syntax of the functions, objects, methods, and properties that you have used. In the Code Editor, incorrect statements are underlined with a blue, jagged line, and you can learn more about the error by holding the mouse pointer over the statement. The following illustration shows the error message that appears in Visual Studio when I type the keyword Case incorrectly as “Csae” and then hold the mouse pointer over the error. This error message appears as a ScreenTip.

If you encounter a run-time error, you often can address the problem by correcting your typing. For example, if a bitmap loads incorrectly into a picture box object, the problem might simply be a misspelled path. However, many run-time errors require a more thorough solution. You can add a structured error handler—a special block of program code that recognizes a run-time error when it happens, suppresses any error messages, and adjusts program conditions to handle the problem—to your programs. I discuss the new syntax for structured error handlers in Chapter 9, “Trapping Errors by Using Structured Error Handling.”

Identifying Logic Errors

Logic errors in your programs are often the most difficult to fix. They're the result of faulty reasoning and planning, not a misunderstanding about Visual Basic syntax. Consider the If…Then decision structure shown below, which evaluates two conditional expressions and then displays one of two messages based on the result.

If Age > 13 And Age < 20 Then     TextBox2.Text = "You're a teenager" Else     TextBox2.Text = "You're not a teenager" End If

Can you spot the problem with this decision structure? A teenager is a person who is between 13 and 19 years old, inclusive, but the structure fails to identify the person who's exactly 13. (For this age, the structure erroneously displays the message “You're not a teenager.”) This type of mistake isn't a syntax error (because the statements follow the rules of Visual Basic); it's a mental mistake, or logic error. The correct decision structure contains a greater than or equal to operator (>=) in the first comparison after the If…Then statement, as shown here:

If Age >= 13 And Age < 20 Then

Believe it or not, this type of mistake is the most common problem in a Visual Basic program. Code that produces the expected results most of the time—but not all of the time—is the hardest to test and to fix.