< Continued from page 1

There are two major ways to deal with errors:

1. Prevent them
2. Handle them when they can't be prevented

The major problem that causes errors in programs is data that isn't what the program expected. The major way to solve this problem is to ensure that the data that you expect to process is actually the data that is received. Three "compiler options" help ensure that the data types in your program are exactly what your program expects:

• Option Explicit
• Option Strict
• Option Infer

(Option Compare is another compiler option, but it doesn't do anything like the previous three. This option can have the values Binary or Text and controls whether string comparisons are based on an internal binary representation of strings or a case-insensitive text sort order determined by your system's locale; that is, how people sort text where you live.)

These three compiler options are important because a data type determines how information is stored and processed. These options help catch errors when you're writing your program that could create big problems for people using your programs after they get into production. For example, processing intended for an integer number can crash if a decimal number is used.

A data type could also be one that you define yourself. We've already created a "user defined data type" in the Signature Block program. The SigBlockStruct structure that we defined in an earlier segment is a user defined data type.

If you use them, compiler option statements have to appear before any other source code. You can change the VB.NET Express defaults if you like: Select Tools > Options > Projects and Solutions > VB Defaults. But you probably should use the system defaults.

Option Explicit

Option Explicit tells VB.NET to require a Dim or ReDim statement to declare all of your variables. If you don't declare your variables, you're taking a step backward - almost back to the way VB used to work in VB6 a decade ago. If you use a variable without declaring it, VB.NET doesn't know what type to use. The only type that will work for everything is the Object datatype. (Although Option Infer will allow VB.NET to overcome this. See below.) Using Object datatypes for everything makes your programs run slower and take more memory, and it can also lead to other errors. Option Explicit On is the default setting.

Here's an example of what can happen if you don't use this option.

--------
Click here to display the illustration.
--------

Option Strict

Option Strict is a level above Option Explict because it enforces rules about how the program can convert one type of data into another. When Option Strict is on, implicit data type conversions are only allowed for "widening conversions". In general, this means that VB.NET won't allow you to convert a variable that can contain more information into one that can't contain as much. For example, it won't let you convert an Integer (32 bit integer) into a Short (16 bit integer) even though it might work. (If, for example, there is only a value "1" in the 32 bit integer.) The purpose is to prevent all possible data loss. Leaving Option Strict set to Off has also been called "Option Slow" because the compiler will then add extra code to do the type conversions.

Option Infer

Option Infer was added to VB.NET just a few years ago. It not only helps prevent errors, it also changes what actually happens when your program is compiled. In addition, the default is different if you write a new program compared to code that was upgraded from an earlier version. (To see this, you have to view the options under the Compile tab of the project's Properties window. Looking at it using "Tools > Options > Projects and Solutions > VB Defaults" gives you the wrong answer.) It's tricky!

This option lets you declare variables without explicitly stating a data type. Here's an example:

' No type is declared for myVarDim myVar = "Whatever" Debug.WriteLine(myVar.GetType)
The Immediate window reports that myVar is of type System.String.

But consider this example. If Option Infer is Off, this code actually works:

Dim myVar ' myVar is initially an ObjectmyVar = 12345Debug.WriteLine("After Assignment to Integer: " &myVar.GetType.ToString)myVar = "whatever"Debug.WriteLine("After Assignment to String: " &myVar.GetType.ToString)After Assignment to Integer: System.Int32After Assignment to String: System.String
With Option Infer set to On, the program won't compile and you can fix it before it ever gets into production. If you don't, it can create situations where your program crashes when people are trying to use it. For example, if the String "whatever" was in myVar and the code tried to add that to another number, the program would crash. myVar is initially an Object data type which can hold anything. (Set a breakpoint on the statement after the Dim, run the code, right-click on myVar and select "Go to Type Definition".) It's then converted to an Integer and then converted to a String. All these conversions slow down the code.

--------
Click here to display the illustration.
--------

You should also keep in mind that Option settings are by file. As the illustration below shows, setting an option in one file doesn't change the setting for any other file.

--------
Click here to display the illustration.
--------

In addition to these compiler supported ways to make sure your code is correct, you should also have lots of checking on data to make sure that nothing will go wrong after the programs start being used. In large scale business systems, this is often done in completely separate data validation layers (programs that run before other processing) just to protect the more critical programs. Regular Expressions can help verify that String data is correct. An introduction to using them can be found in this article.

Although your program should do everything possible to prevent an error, sometimes you have to program to respond to errors that can't be prevented. On the next page, we learn about Structured Exception Handling to do that.