Types of Errors

I've stated previously that there are several basic types of errors that can creep into your code. (Aw, let's be honest about it. The errors didn't creep into your code ”you put them there.) Before you can expunge an error, you need to understand its type and its exact nature. There are three basic types of errors: syntax errors, semantic errors, and logic errors. Let's look at these a little more closely.

Syntax Errors

Every program statement in Visual Basic .NET is comprised of expressions. These expressions are built up from operators and operands. For example, you know that the statement

 x = y 

is an assignment expression. It has two operands, x and y , and one (binary) operator, the equal sign. In this case, the program statement is comprised of a single expression.

When you type in any program statement, the instant that you press the Enter key, Visual Basic .NET examines what you typed in to see whether it forms a valid Visual Basic .NET program statement. If the line you typed in doesn't form a valid program statement, Visual Basic .NET places a squiggly line under the offending section of the line containing the error. An example of this is shown in Figure 19.1.

Figure 19.1. Example of a syntax error involving an incomplete expression.

If you look near the middle of the figure, you'll see a squiggly line under the equal sign. What does not show up is the cursor that I placed over the squiggly line. When I did this, Visual Basic .NET displayed the Expression expected error message that you see in Figure 19.1. This message tells me that Visual Basic .NET was expecting an expression, but my line did not form a complete expression. (Obviously, I need to add an operand on the right side of the assignment operator.)

When you begin programming with Visual Basic .NET, you should expect to make a lot of syntax errors. After all, this is a new language, and very few people instantly become fluent in any new language. The main point is not to let these syntax errors discourage you. Everyone goes through this phase, and you will, too. To become a Visual Basic .NET programmer, you have to pay your dues, and wading through a swamp of syntax errors is just one of the costs.

The good news is that Visual Basic .NET is extremely good at catching syntax errors. Indeed, it tells you about them the moment you make them. Placing the cursor over the squiggly line causes Visual Basic .NET to issue a message that's usually sufficiently complete for you to figure out what needs to be corrected. After making the correction, the squiggly line should go away if the change results in a syntactically correct program statement.

As you gain experience with Visual Basic .NET, you'll find that the number of syntax errors you make tends to decrease. You'll be able to write dozens and dozens of lines of code and never see the dreaded squiggly line. Yep, the syntax errors virtually disappear after a while. As you gain programming experience and sophistication with Visual Basic .NET, so will your errors. You're ready to move to level 2 errors.

Semantic Errors

We talked about semantic errors before. Just as the English language has rules about how sentences are formed from nouns and verbs, Visual Basic .NET has rules about how program statements are formed from keywords and expressions. If you don't follow the rules, syntax errors like those we discussed in the previous section result.

However, it's possible to obey the rules of the language but construct a sentence that doesn't make sense. Statements that obey the syntax rules, but are taken out of context, are called semantic errors. As an example of a semantic error, we used this sentence: "The dog meowed." This obeys the basic rules of English in that the sentence has a noun and a verb, but the sentence doesn't make sense because it does not have the proper context for the noun and verb.

Semantic errors are a little difficult to isolate and change. The reason is because Visual Basic .NET cannot detect semantic errors while you are writing the program the way it can detect syntax errors. For example, suppose that you have the following code fragment in your program:

 Dim i As Byte  Dim j As Integer j = 256 i = CByte(j) 

As you learned in Chapter 4, "Data Types and Numeric Variables," a Byte data type has a range of values from 0 through 255. In this code fragment, however, we're trying to assign the value 256 into a Byte variable named i . If we type this code into our program, Visual Basic .NET doesn't complain. The reason is because each program statement conforms to the syntax rules of Visual Basic .NET.

However, if we try to run the program, Visual Basic .NET issues an error message stating :

 An unhandled exception of type 'System.OverflowException' occurred in ErrorViewer.exe  Additional information: Arithmetic operation resulted in an overflow. 

This is an example of a semantic error. Visual Basic .NET issued the error message because we attempted to use the variable i , which is a Byte variable, in the context of an Integer variable.

Note the difference between a syntax error and a semantic error. Syntax errors are caught at design time, while you are writing the program. Semantic errors manifest themselves at runtime, while the program is running.

Why can't Visual Basic .NET catch semantic errors at design time as it does for syntax errors? The reason is because syntax errors are checked one line at a time as you enter them. Semantic errors, however, usually involve errors that span multiple lines. In the earlier code fragment, the semantic error is actually caused by a mismatch between the data item being defined (that is, variable i ) in the first code statement and when it is used in the last assignment statement. Therefore, Visual Basic .NET doesn't detect this type of error until runtime.

Still, Visual Basic .NET is a terrific help because it (eventually) does give you a very clear error message, telling you the nature of the program error. True, it waits until runtime to tell you about the error, but that's still a huge help versus trying to track down this type of error without Visual Basic .NET's help.

Once again, as you gain experience, you'll code fewer and fewer semantic errors. In most cases, semantic errors are called flat-forehead errors. Semantic errors earn this name because, on their discovery, you smack the heel of your hand into your forehead while saying, "How could I make such a stupid mistake!" Join the crowd it's all part of becoming a programmer.

Still, even the semantic errors begin to disappear from the landscape as you gain experience. You have finally graduated to the realm of the level 3 error: the logic error.

Logic Errors

Just about any error that isn't a syntax error or semantic error is a logic error. As a general rule, a logic error is simply the manifestation of a difference between what you thought would happen as the program ran and what actually did happen. Your code obeys all the syntax and semantic rules, but the program doesn't produce the results that you expected. The bad news is that, because you have followed all the syntax and semantic rules, Visual Basic .NET can't detect logic errors at either design time or runtime. The good news is that the Visual Basic .NET debugger is a pretty good detective, and you can use it to help track down the culprit.

In terms of the five program steps we discussed in Chapter 3, "Thinking About Programs," the Output step frequently reveals the logic error. However, the actual place where the logic error is hiding could be anywhere in the Initialization step, the Input step, the Processing step, or even the Output step itself. Therefore, the first thing that needs to be done is to isolate the logic error. That is, assuming that the error is repeatable, your first job is to find out which program step is hiding the error. The Visual Basic .NET debugger is the perfect ally for such a task.