Appendix E VBScript Error Codes and the Err Object

Here you'll find all the error codes associated with VBScript along with the Err object.

Runtime Errors

Runtime errors occur wherever your script attempts to perform an invalid action. The vast majority of these errors should be caught during the debugging and testing stage. VBScript contains 43 runtime errors, which are listed in the following table with their decimal and hexadecimal representations.

Decimal Hexadecimal Description

5

800A0005

Invalid procedure call or argument

6

800A0006

Overflow

7

800A0007

Out of memory

9

800A0009

Subscript out of range

10

800A000A

This array is fixed or temporarily locked

11

800A000B

Division by zero

13

800A000D

Type mismatch

14

800A000E

Out of string space

17

800A0011

Can't perform requested operation

28

800A001C

Out of stack space

35

800A0023

Sub or Function not defined

48

800A0030

Err in loading DLL

51

800A0033

Internal error

91

800A005B

Object variable not set

92

800A005C

For loop not initialized

94

800A005E

Invalid use of Null

424

800A01A8

Object required

429

800A01AD

ActiveX component can't create object

430

800A01AE

Class doesn't support Automation

432

800A01B0

File name or class name not found during Automation operation

438

800A01B6

Object doesn't support this property or method

445

800A01BD

Object doesn't support this action

447

800A01BF

Object doesn't support current locale setting

448

800A01C0

Named argument not found

449

800A01C1

Argument not optional

450

800A01C2

Wrong number of arguments or invalid property assignment

451

800A01C3

Object not a collection

458

800A01CA

Variable uses an Automation type not supported in VBScript

462

800A01CE

The remote server machine does not exist or is unavailable

481

800A01E1

Invalid picture

500

800A01F4

Variable is undefined

502

800A01F6

Object not safe for scripting

503

800A01F7

Object not safe for initializing

504

800A01F8

Object not safe for creating

505

800A01F9

Invalid or unqualified reference

506

800A01FA

Class not defined

507

800A01FB

An exception occurred

5008

800A1390

Illegal assignment

5017

800A1399

Syntax error in regular expression

5018

800A139A

Unexpected quantifier

5019

800A139B

Expected ² ] ² in regular expression

5020

800A139C

Expected ² ] ² in regular expression

5021

800A139D

Invalid range in character set


Syntax Errors

Syntax errors occur wherever your script contains statements that do not follow the pre-defined rules for that language. This type of error should be caught during development. VBScript contains 49 syntax errors, listed in the following table with their decimal and hexadecimal representations.

Decimal Hexadecimal Description

1001

800A03E9

Out of memory

1002

800A03EA

Syntax error

1005

800A03ED

Expected ²( ²

1006

800A03EE

Expected ²) ²

1010

800A03F2

Expected identifier

1011

800A03F3

Expected ²= ²

1012

800A03F4

Expected ²If ²

1013

800A03F5

Expected ²To ²

1014

800A03F6

Expected ²End ²

1015

800A03F7

Expected ²Function ²

1016

800A03F8

Expected ²Sub ²

1017

800A03F9

Expected ²Then ²

1018

800A03FA

Expected ²Wend ²

1019

800A03FB

Expected ²Loop ²

1020

800A03FC

Expected ²Next ²

1021

800A03FD

Expected ²Case ²

1022

800A03FE

Expected ²Select ²

1023

800A03FF

Expected expression

1024

800A0400

Expected statement

1025

800A0401

Expected end of statement

1026

800A0402

Expected integer constant

1027

800A0403

Expected ²While ² or ²Until ²

1028

800A0404

Expected ²While ², ²Until ², or end of statement

1029

800A0405

Expected ²With ²

1030

800A0406

Identifier too long

1013

800A0407

Invalid number

1014

800A0408

Invalid character

1015

800A0409

Unterminated string constant

1034

800A040A

Unterminated comment

1037

800A040D

Invalid use of ²Me ² keyword

1038

800A040E

²loop ² without ²do ²

1039

800A040F

Invalid ²exit ² statement

1040

800A0410

Invalid ²for ² loop control variable

1041

800A0411

Name redefined

1042

800A0412

Must be first statement on the line

1044

800A0414

Cannot use parentheses when calling a Sub

1045

800A0415

Expected literal constant

1046

800A0416

Expected ²In ²

1047

800A0417

Expected ²Class ²

1048

800A0418

Must be defined inside a Class

1049

800A0419

Expected Let or Set or Get in property declaration

1050

800A041A

Expected ²Property ²

1051

800A041B

Number of arguments must be consistent across properties specification

1052

800A041C

Cannot have multiple default property/method in a Class

1053

800A041D

Class initialize or terminate do not have arguments

1054

800A041E

Property Set or Let must have at least one argument

1055

800A041F

Unexpected ²Next ²

1057

800A0421

²Default ² specification must also specify ²Public ²)

1058

800A0422

²Default ² specification can only be on Property Get


The Err Object

Errors usually make their way into code and as such it's important to be able to spot them and remove them. At the core of this is error handling using the Err object.

Let's take a quick tour of the Err object and the On Err statement and look at ways to make use of them in VBScript code.

Err Object

The Err object is the heart and soul of error handling in VBScript, and exposes information about runtime errors through its properties. Unlike other objects in VBScript, it is an intrinsic object with global scope; hence, there is no need to declare and initialize the Err object.

Initially the Err properties are either zero-length strings or , and when a runtime error occurs the properties of the Err object get populated by the generator of the error (e.g. VBScript, an Automation object, or by the programmer). Err.Number contains an integer, and Number is the default property of the Err object. It is easy to test whether the error actually occurred with an If ErrThen statement because of automatic conversion between integer and Boolean subtypes : the integer (no error) converts to Boolean False , and all other numbers evaluate to True .

The following example illustrates a partial IE VBScript (although it could just as easily be from a .wsc , or .hta file) in which the programmer raises one of the predefined VBScript errors. Note that the Err object is not declared and it cannot be created as a separate object.


 

Err Object Properties

Let's take a look at the Err object properties.

Description

The Description property returns or sets a descriptive string associated with an error. By default this is a zero-length string until the property is set by the programmer or by the generator of an error. The description is useful when displaying or logging errors and when raising custom errors. If the programmer raises one of the default runtime errors, the Description property contains the string associated with the error.

Syntax



Err.Description [= stringexpression]


Name Subtype Description

Err

Err Object

This is always the Err Object

Stringexpression

String

A string expression containing a description of the error

Example Usage


 

This sample script will produce Variable in undefined inside a message box.

HelpContext

The HelpContext property is used to automatically display the Help topic specified in the HelpFile property. This property either sets or retrieves the value of the help context. If both HelpFile and HelpContext are empty, the value of Number is checked. If

Number corresponds to a VBScript runtime error value, then the VBScript help context ID for the error is used.

This property is rarely used, and requires coordination between the person authoring the Help system and the scripter.

Finally, use of the HelpFile and HelpContext only make sense in a non-IE setting with the older .hlp system. Newer HTML help simply uses HTML documents, which may be displayed under most circumstances using techniques discussed in HTML Help manuals.

The following sample illustrates the use of the traditional .hlp files with the Windows Script Host.

Syntax



Err.HelpContext [= contextID]


Name Subtype Description

Err

Err Object

This always is the Err Object

ContextID

Integer

Optional. A valid identifier for a Help topic within the Help file

Example Usage



On Error Resume Next




Dim Msg




Err.Clear




Err.Raise 6 Generate Overflow error.




Err.Helpfile = c:  windows help yourHelp.hlp




Err.HelpContext = 21




If Err.Number <> 0 Then




Msg = Press Help to see & Err.Helpfile & topic for & _




the following HelpContext: & Err.HelpContext




MsgBox Msg, , error: & Err.Description, Err.Helpfile, Err.HelpContext




End If


HelpFile

The HelpFile property is used to set and retrieve a fully qualified path to a programmer- authored Help File. Often it is used in conjunction with the HelpContext property-see the notes and the earlier example. The most common way of setting the value is through the Err.Raise method.

Syntax



Err.HelpFile [= filepath]


Name Subtype Description

Err

Err Object

This always is the Err Object

Filepath

String

Optional. Fully qualified path to the Help File

Number

This is the default property of the Err object, and returns or sets a numeric value specifying an error. Custom error handling functions utilize the Number property to diagnose the runtime error.

When setting or retrieving a custom error, the vbObjectErr constant is used to ensure that custom errors do not conflict with VBScript and common Automation Errs .

Syntax



Err.Number [= errornumber]


Name Subtype Description

Err

Err Object

This is always the Err Object

Errornumber

Integer

An integer representing a VBScript error number or an SCODE error value. SCODE is a long integer value that is used to pass detailed information to the caller of an interface member or API function

Example Usage



On Error Resume Next




Err.Raise vbObjectError + 16, ,CustomObject Error Raise Custom Error #16.




If Err.Number <> 0 Then (If Err Then) can be used too




MsgBox (Error # & CStr(Err.Number) & & Err.Description)




End If


The preceding sample code sets a custom error number in Err.Number through the Err.Raise method, and then displays the return value through a Message Box ( MsgBox ).

Source

The Source property sets or returns the name of the object or application that reported the error. Most commonly the source is the class name or ProgID of the object generating the error.

Most of the time the Source property will show ³Microsoft VBScript ³, but in cases where the error occurs while accessing a property or method of an Automation object, the source property will show the component's class name. This is not only useful because it allows for a greater degree of granularity (or visibility) in error handling, but it also allows for better error display and logging possibilities. This property can be set through the Err.Raise method in both VBScript and in custom COM components .

Syntax



Err.Source [= stringexpression]


Name Subtype Description

Err

Err Object

This always is the Err Object

Stringexpression

Integer

A string expression representing the application that generated the error

Example Usage



On Error Resume Next




Err.Raise vbObjectError + 1, cTestClass, CustomObject Error




If Err.Number <> 0 Then (If Err Then) can be used too




MsgBox (Error # & CStr(Err.Number) & & Err.Description & Source: & Err.Source)




End If


Err Object Methods

Let ²s take a look at the Err object methods.

Clear

The Clear method resets all of the properties of the Err object to either or a zero-length string. The Err object should ideally be reset after an error has been handled because of the deferred nature of error handling in VBScript, to avoid the potential mistake of handling the same error twice.

The Err object is additionally cleared by any of the following statements:

  • On Error Resume Next
  • On Error Goto
  • Exit Sub
  • Exit Function

Therefore, error-handling functions must be called before any of the preceding statements are executed.

Syntax



Err.Clear


Name Subtype Description

Err

Err Object

This always is the Err Object

Example Usage



On Error Resume Next The Err Object is Reset




Err.Raise 5




Err.Clear




If Err.Number = 0 Then (If Err Then) can be used too




MsgBox (Error has been reset: Err.Number - & CStr(Err.Number))




End If


Raise

The Raise method generates a runtime error. All of the parameters of the Raise method, except for its number, are optional. When optional parameters are not specified, and the Err object has not been cleared, old values may appear.

The best practice is to use Err.Clear after error handling, and to inspect the Err object before using Err.Raise (in case an error has occurred in the meantime). When raising custom error numbers, the vbObjectErr constant should be added.

The HelpFile and HelpContext parameters are used with the traditional .hlp help, and not with the HTML help systems.

Raising errors is a popular technique to stop the execution of a procedure, and handle it via some error handling function. You may raise errors when data is invalid, and when you want to pass an error up the call stack. This is a popular technique when you want to change one error into another, so that it can be handled properly.

Syntax



Err.Raise (number, source, description, helpfile, helpcontext)


Name Subtype Description

Err

Err Object

This is always the Err Object

Number

Long

This identifies the nature of the error. All VBScript (predefined and user -defined) error numbers are in the range 0-65535

Source

String

This identifies the name of the object or application that generates the error. When setting this property for Windows Script Components, use the ProgID form.

If nothing is specified, the current ID of the project is used; often, it just defaults to ²Microsoft VBScript ²

Description

String

This is the description of the error. If unspecified, the value in number is examined. If it can be mapped to a VBScript runtime error code, a string provided by VBScript is used as the description. If there is no VBScript error corresponding to number, a generic error message is used

Helpfile

String

This is the fully qualified path to a customized help file in which help on this error can be found. If unspecified, VBScript uses the fully qualified drive, path, and file name of the VBScript help file

Helpcontext

Integer

This is the context ID identifying a topic within helpfile that provides help for the error. If omitted, the VBScript help file context ID for the error corresponding to the number property is used, if it exists

Example Usage



Dim strMsg




On Error Resume Next




Err.Raise vbObjectError + 1, prjProject.clsClass, Custom Error,




c: windowsYourHelpfile.hlp, 1




If Err.Number <> 0 Then




strMsg = Error Number: & CStr(Err.Number) & vbCrLf




strMsg = strMsg & Description: & Err.Description & vbCrLf




strMsg = strMsg & Source: & Err.Source




If Err.HelpFile <> Then




strMsg = strMsg & vbCrLf & Press Help to see the help file




MsgBox strMsg, , Error: & Err.Description, Err.Helpfile, Err




.HelpContext




End If




MsgBox strMsg No Help file available here




Err.Clear




End If


This example shows a common way of raising an error in Windows Script Host, where the help file is readily available.

vbObjectError Constant

This is a built-in constant that can be used in conjunction with programmer-defined errors and Err.Raise . It does not have to be declared or initialized ; its decimal value is -2147221504 (or -0 (8004000 in hexadecimal). Whereas previous examples have shown how to use the vbObjectError constant with the Err.Raise method, the following example shows a skeleton of a centralized error handler that combines Select Case with custom errors.

Example Usage



If Err.Number <> 0 Then this should call separate subs




Select Case Err.Number




Case vbObjectError + 1




call sub handling error 1




Case vbObjectError + 3




call sub handling error 3




Case Else




call reporting sub to display errors




End Select




End If


On Error Resume Next

This statement enables error handling within the scope of a script or a procedure. Without the On Error Resume Next statement, the default runtime error handler displays the error and stops the execution of the script.

On Error Resume Next continues the execution of the script on the next line following the error. The error handling routine has to exist within the same scope as this statement. The statement becomes inactive with a call to another procedure or when an On Error Goto statement is used.

Syntax



On Error Resume Next


Tip  

When Internet Explorer's advanced option Disable Script Debugging is not selected and the Script Debugger is installed on the same system, On Error Resume Next does not go into effect; instead, the browser automatically goes into the ³debug ³ mode. So, when testing the effectiveness of your error handler through Internet Explorer, make sure that this option is selected.

On Error Goto 0

The On Error Goto statement disables the error handling that was enabled by On Error Resume Next . This statement is especially useful in the testing stage, when there is a need to identify certain errors and yet handle others. On Error Goto can be placed immediately after the error handling procedure is called.

Like On Error Resume Next , this statement is also scope dependent.

Syntax



On Error Goto 0


Scope of On Error Statement and Differences Between VBScript's and VBs (or VBAs) Error Handling

It is important to understand the scope of the On Error statement; otherwise your error handling procedures may never execute. VBScript-unlike its parent language-does not support labels, and it does not support the VB On Error Goto label. Thus, VBScript provides support only for in-line error handlers that can cause understandable grief . Basically, in order to mimic a block of code in VB that would respond to an On Error Goto label statement you might be inclined to use several If Err Then statements in order to check for an error with each single line of execution. However, with a little bit of programming, this can easily be achieved by enabling an error handler around a given procedure. Should one of the lines in the procedure fail, the error can be thrown up the calling stack. Of course, there is no Resume statement, which complicates some of the scripting. This can only be circumvented by trying to correct the problem that generated the error and attempting to call the procedure again.

Before we look at some error handling techniques, let's examine the scope of error handling. The following script illustrates an important concept behind the scope of the error-enabling and error-disabling statements, as well as showing the differences in scope and the importance in clearing of errors.



Sub TestError()




On Error Resume Next




Err.Raise 6 Execution will continue




MsgBox (TestError: Error # & CStr(Err.Number) & & Err.Description)




Err.Clear




End Sub




Sub TestError2()




Err.Clear Execution stops, moves up in scope




MsgBox (TestError2: This will never Show Up)




End Sub




Main body of the script




TestError() has local Error Handler no need for global Handler




On Error Resume Next




Call TestError()




If Err.Number <> 0 Then




MsgBox (Global: Error # & CStr(Err.Number) & & Err.Description)




Err Clear




Else




MsgBox (Global: No Error, It was handled locally and cleared)




End If




TestError2 has no local error handler




Call TestError2()




If Err.Number <> 0 Then




MsgBox (Global: Error # & CStr(Err.Number) & & Err.Description)




Err.Clear




End If




Global script Error handling is turned off, cause crash




On Error goto 0




Call TestError2()


Upon execution, the error is first handled locally, and after it is cleared, it is ignored. Next, the calls to the Test Error2() subroutine are first handled by the global error handler and, after it is disabled on the second-last line, a runtime error appears.

Now, to consider the importance of clearing errors and the scope of On Error Resume Next , we make two adjustments, commenting out certain code.



Sub TestError()




On Error Resume Next




Err.Raise 6 Execution will continue




MsgBox (TestError: Error # & CStr(Err.Number) & & Err.Description)




REM Err.Clear




End Sub




Sub TestError2()




Err.Clear Execution stops, moves up in scope




MsgBox (TestError2: This will never Show Up)




End Sub




Main body of the script




TestError() has local Error Handler no need for global Handler




REM On Error Resume Next


With these changes, an error message is still displayed after the call to TestError() , but the first call to the TestError2() subprocedure results in an invocation of the default error handler, and stoppage of the script immediately after the call, that is, the On Error Resume Next statement was local in scope to the TestError() subprocedure.

The following code illustrates the possibility of mimicking the On Error Goto label statement by encompassing a block of code in a procedure, rather than trapping errors inline, as in VB. Here the scripter can invoke an error handler at a higher level rather than at the level where the error occurred (in this case, a procedure without a local error handler).



Option Explicit




Dim intZero, intNonZero, intResult




intZero = 0




intNonZero = 1




Sub TestError()




Statements that will execute




MsgBox (This will always execute)




now cause an error




intResult = intNonZero / intZero causes error 11




Statements that will not execute if error occurs




MsgBox (Finally executed, Result = & CStr(intResult))




End Sub




simulate On Error Goto Label by having a block of code in a sub




On Error Resume Next




Call TestError()




If Err.Number = 11 Then




MsgBox Division By Zero - may still continue & vbCrLf & Err.Description




Err.Clear




intZero = 1




TestError()




End If




On Error Goto 0 kill other error handling


Error Handling in Internet Explorer

Besides VBScript itself, some Web authors might also turn to DHTML events. Internet Explorer's DHTML object model supports a variety of events, including events occurring as a result of an error. Essentially, this allows for a different degree of control when authoring scripts for IE. Thanks to the GetRef() function, which returns a pointer to a function, it is now possible to bind VBScript procedures to an event.

For instance, the following line will execute the RunMySub procedure in response to the Window .Onload event in IE.



Set Window.Onload = GetRef(RunMySub)


Similarly, you can write procedures that will execute when the OnError event is fired , either for an element or for the window object.

There are two additional techniques for error handling in IE:

  • Centralized, through the use of the window.onerror event
  • Decentralized, through the use of the element.onerror event

The following code example illustrates the old and the new syntax for handling DHTML errors.

Old Syntax



Function element_onerror (message, url, line)


element is the name of the element or window.


 

New Syntax



Set element.onerror = GetRef(functionName)


The new syntax allows us to bind functions to events, just like in JScript. Again, element is the name of the element or window, and functionName is an actual function or a sub.


 

There are a few important differences between the VBScript's error handling and the use of the onerror event in IE. Following is the list of a summary of the onerror IE handlers:

  • Execution does not resume on the next line. The script may resume with the next user action or handled event-for example, the user ³clicks ³ on another element. If you want greater error-handling control in individual procedures executed in the browser, the On Error Resume Next statement should be used.
  • All errors pertaining to the element (or window) are handled by the event unless handled via VBScript's On Error Resume Next technique.
  • Errors can be passed to a higher-level element via event bubbling.
  • Custom errors cannot be created; there is no Err.Raise counterpart in the DHTML object model.






VBScript Programmer's Reference
VBScript Programmers Reference
ISBN: 0470168080
EAN: 2147483647
Year: 2003
Pages: 242
Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net