VBScript error
An error is when something unexpected happens that causes the code to stop executing and alert the user of a problem.
Error types
The list of VBScript errors lists errors by number, explains what kind of common mistakes cause the error in the code, and tips on how to fix it.
There are three general types of errors in programming [1]: parsing, or syntax, errors, run-time errors, and logical errors.
Parsing errors occur when a mistake with the syntax was made. An error with a number in the 1000s range will be raised when the code is loaded into memory and "parsed".
- "The
Option Explicitstatement is one means of avoiding syntax errors. It forces you to declare, in advance, all the variables to be used in the application. Therefore, when those variables are used in the code, any typographic errors are caught [by the special run-time error #500] and can be fixed." -MSDN
Run-time errors occur when a mistake is not noticeable when parsing the code, but appears when the values are unable to be computed, for example; appearing when the code is "running". An error message will be raised.
Logic errors are a type of error where the result of an operation is not expected or undesired, but does not raise an error. These errors are often the hardest to find.
StealthBot scripting errors
In StealthBot, error messages are displayed with great detail to help script writers easily fix their mistakes. Template:BotText
The error can say either run-time or parsing, since the bot can determine that, the error number, what script (and #include if appropriate), line, and column. It shows a short description and even copies the contents of the line to the bot window.
Handling errors
Most times, it's preferred to avoid errors as best as possible. For example, if you get a division by zero from a statement, have an If block check if the denominator is zero, and if so do something else such as respond to the command so that more than the bot owner knows of the command's failure.
Sometimes it may not be possible to do this. In this case, you can use the On Error statement and check the Err object.
On Error Resume Next
When an error is encountered, the first thing the script does is stop parsing or executing. When a parsing error occurs, nothing is parsed, so the error cannot be handled. Fix your syntax.
When a run-time error occurs, the script "can" continue by running the next line, since the script is already parsed. To do this, use the statement On Error Resume Next.
On Error Resume Next Var1 = 1 / VarDenom
However, once an error occurs, the information of that error is stored in the special Err object.
Err object
The error object stores error information.
Use it to do something when error #11 (division by zero) occurs:
On Error Resume Next
Var1 = 1 / VarDenom
If Err.Number = 11 Then
Err.Clear
Cmd.Respond "The denominator was zero."
End If
List of properties and methods
- .Description
- .Number
- .Source
- .HelpFile
- .HelpContext
- .Raise
- .Clear
Description property
The description property returns the short description that the error generated as a string. This will be user language dependent.
Number property
The number property returns the error number. Specifically useful is this will be zero when there is no error and non-zero when there is an error (If Err.Number <> 0 Then is used most often). This number is specific to the same error regardless of language, so you can check for specific errors as well.
Source property
Unless you are using the Execute or ExecuteGlobal built-in functions and attempting to parse code, this property will always contain the string "Microsoft VBScript runtime error".
HelpFile property
In most cases, this will be an empty string. This is
Raise method
Syntax:
Err.Raise number, source, description, helpfile, helpcontext
This will raise a custom error.
Clear method
Syntax
Err.Clear
This will clear the current error message.
On Error GoTo 0
Use the On Error GoTo 0 statement to do the reverse: set the error handler to stop execution when it runs into a run-time error. This is the default behavior.
On Error statements last for the duration of their scope: when set to Resume Next in a subroutine it will return to GoTo 0 when the subroutine exits.
