VBScript in a Nutshell

Common Problems Areas, and How to Avoid Them

There is much to be said for the old maxim, “The best way to learn is by making mistakes.” Once you have made a mistake, found out what you did wrong, and rectified the error, you will—in general— have a much better understanding of the concepts involved and of what is needed to build a successful application. But to save you from having to experience this painful process of trial and error in its entirety, we’d like to share with you some of the most common errors that ourselves and other programmers we’ve worked with have made over more years than we care to remember. These types of errors are actually not unique to VBScript, nor in fact to VB, but to programming in general. In approximate order of frequency, they are:

• Straight in at No. 1 in the charts this week are syntax errors generated by typing errors. This is a tough one; typing errors —the misspelled function call or variable name—are always going to creep into code somewhere. They can be difficult to detect, particularly because they are typing errors—we frequently train our eyes to see what should be there, rather than what is there. When the effect of the typing error is subtle, it becomes even more difficult to detect. For instance, in a client-side script, we had spelled LANGUAGE as LANGAUGE in coding the <SCRIPT> tag. The result was that MSIE immediately began reporting JavaScript syntax errors. This isn’t surprising, given that in the absence of a valid LANGUAGE attribute, MSIE used its default scripting language, JScript. But when confronted with this situation, it takes a while to recognize the obvious—that the LANGUAGE attribute for some reason is improperly defined; instead, it seems that Internet Explorer and VBScript are somehow mysteriously “broken.” The only real way to reduce the time spent scratching your head is to build code in small executable stages, testing them as you go. Another good tip is to use individual small sample scripts if you are using a function or set of functions for the first time and aren’t sure how they’ll work. That allows you to concentrate on just the new functions rather than on all the rest of the script as well. And perhaps the most effective technique for reducing troublesome misspelling of variables is to include the Option Explicit directive under the first <SCRIPT> tag in ASP, MSIE, and WSH/XML scripts, and at the top of the page of WSH and Outlook form scripts. This way, any undefined variable—which includes misspelled variables—is caught at compile time.

• Running a close second are type mismatches by everyone’s favorite data type, the variants. (Type mismatches occur when the VBScript engine is expecting data of one variant subtype—like a string—but is actually passed another data subtype— like an integer.) Actually, type mismatch errors are fairly uncommon in VBScript, since most of the time the variant data type itself takes care of converting data from one subtype to another. That tends, though, to make type mismatch errors all the more frustrating. For instance, in Example 4.5, if we hadn’t used the statements:

  nNum1 = CDbl(Request.Form("txtNum1"))
  nNum2 = CDbl(Request.Form("txtNum2"))
  nQuot = CDbl(Request.Form("txtQuotient"))

  to convert the form data submitted by the user to numeric data, our application would not have functioned as expected. The best way to reduce or eliminate type mismatch errors is to adhere as closely as possible to a uniform set of VBScript coding conventions. (For a review of coding conventions and their significance, see Chapter 2.) For instance, when you know that a variable is going to hold a string, use a variable name like strMyVar to indicate its subtype, etc. Code becomes easier to use if you can tell instantly that some operation (like strMyString = intMyInt * dteMyDate) doesn’t make sense, but you’re none the wiser if your line of code reads a = b * c.

• In the third position is an error that occurs frequently when using arrays, Subscript Out Of Range. It actually doesn’t take much to eliminate this error for good. All you have to do is check the variable value you’re about to use to access the array element against the value of the UBound function, which lets you know exactly what the maximum subscript of an array is.

• Approximately the fourth most common error is division by zero. If you try to divide any number by zero, you’ll kill your script stone dead. While it’s very easy to generate a division by zero error in a script, it’s also not at all difficult to prevent it happening. A division by zero error is easy to diagnose: whenever a variable has a value of zero, it’s likely to cause a problem. So all your script has to do is check its value and, if it turns out to be zero, not perform the division. There’s no rocket science here! Simply use an If x = Then conditional statement, where x is the variable representing the divisor.