Re: Error handling in vbscript.
From: Joe Earnest (joeearnestNO_at_SPAMqwest.netPLEASE)
Date: 03/15/04
- Next message: Fritz: "Re: Don't want to use a Macro"
- Previous message: Ray at <%=sLocation%> [MVP]: "Re: Error handling in vbscript."
- In reply to: James Houston: "Error handling in vbscript."
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 15 Mar 2004 11:09:22 -0700
Hi,
"James Houston" <houstjd@yahoo.com> wrote in message
news:uVY3rGrCEHA.1604@TK2MSFTNGP11.phx.gbl...
> Does vbscript support line labels ? If I enter code like:
>
> on error goto ErrLine
>
> (some code)
>
> ErrLine:
> select case err
> (some more code)
> end select
>
> I get an error message saying 'Syntax error on line 1'.
>
> Can someone point me to a good online resource about error handling in
> vbscript? Thanks in advance.
Unfortunately, the MS WSH CHM file has a few incorrect statements about
error handling and does not adequately discuss scope.
Here is my (recently revised) standard schpeal on VBS error handling.
--- Error handling in VBS is limited to two On Error ... statements: (1) On Error Resume Next, which initiates runtime error trapping and continues to the next statement, if an error occurs; and (2) On Error Goto 0, the standard state, which exposes runtime errors and terminates the code. Only runtime, not syntax, errors will be trapped, although VBS handles many syntax-like errors at runtime (e.g., mistyped variable and function names) that can be masked by error-trapping. The Err object appears to be somewhat incorrectly documented in the MS VBS documentation. That documentation indicates that the On Error Resume Next statement, but not the On Error Goto 0 statement, will implicitly clear (reset) any error data; and that Exit ... and End ... procedure statements will implicitly clear (reset) any error settings. In fact, VBS handles additional error object instances or settings in a scope-sensitive manner; both of the On Error ... statements will implicitly clear (reset) any error data; and Exit ... and End ... procedure statements do not implicitly clear (reset) any error settings. The Err object is an intrinsic global object available under all hosts. When an error occurs, VBS will start with the present procedure, if any, and, if no error-trapping is presently in force in the procedure, will then look back along the call stack to the global script, to ascertain whether there is error-trapping status in effect at any level in the stack. If it finds one, it will jump to the next statement at that level (potentially after the call to the error-producing procedure or one of its parent procedures). If not, VBS displays a runtime error message and terminates. The Err object has two intrinsic methods: (1) Clear, which expressly clears the Err object properties and resets them, as if no error has occurred, and (2) Raise, which simulates a runtime error. Both of the On Error ... statements will implicitly clear (reset) the Err object properties. If exiting a procedure after a trapped error, without first executing an Err.Clear statement or proceeding through an On Error Goto 0 statement, the status of the Err object properties will be maintained, and any conditional statement in the script back along the call stack relying on that status (e.g., if err then ... ) will be implemented, regardless of whether error-trapping status is presently in force in that code. The Err object has two particularly significant properties: (1) Number, which returns zero, if no error has been registered or if an error has been cleared (reset), or a non-zero long integer error code, indicating the error that has been registered; and (2) Description, which is a text description of the error. Number is the default property and can be omitted in assignment or condition statements (e.g., cErr= err or if err then ... ). While the error code number is usually sufficient to identify an error, text descriptions are occasionally different for different errors represented by the same error code, so resort to the text of the description may sometimes also be necessary, to better resolve the nature of the error. Invocation of error-trapping through On Error Resume Next in prior script in the calling stack does not extend into a called procedure's scope. This permits a script to place a generic error handler earlier in the calling stack, while still using specific error handlers in the later procedures. Unless one has well-crafted and specific plan for catch-all error handling in a script of limited scope, however, it is usually best to set local error handling only, and for as narrow a range as feasible, to avoid masking routine errors that can be corrected, as well as unforeseen errors that will be mistaken for a different type of error. VBS error handling lacks call stack tracing, but that aspect can be added with privately implemented procedures or classes. Similarly, VBS error handling lacks the ability to jump to different line numbers on errors. That ability can be partially simulated, where necessary, through procedure design and the implementation of script arguments that call those procedures in different order, where the script reruns itself with the appropriate argument and quits, when a specific error is encountered. One special area of error handling involves the use of With blocks. A With block must always be literally exited, by allowing operation to proceed through the End With statement. As the MS WSH documentation makes clear, you cannot exit a With by simply terminating the script or through any of the standard block exits, without risking "memory leaks" and/or some very peculiar errors, including some unenlightening error messages generated when the script tries to quit. So it may be necessary to use one or more faux-loops inside a With block, to exit to the End With statement, prior to acting on the error. --- Joe Earnest --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.564 / Virus Database: 356 - Release Date: 01-19-04
- Next message: Fritz: "Re: Don't want to use a Macro"
- Previous message: Ray at <%=sLocation%> [MVP]: "Re: Error handling in vbscript."
- In reply to: James Houston: "Error handling in vbscript."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
