VbScript With Error Handling

VBScripting- Runtime Error Handling::::: http://msdn.microsoft.com/en-us/ http://msdn.micr osoft.com/en-us/library/xe43cc8d library/xe43cc8d(VS.85).aspx (VS.85).aspx

VbScript with error handling Ever thought about how to handle unexpected runtime errors in your VBScripts? It’s so cool when everyting works like you expect it to, but what if something goes wrong? You are the person in charge of the network and you make a VBScript that maps a printer to the users computers each time the person logs on the network. For instance with the following code:

Option Explicit Dim strPrinterUNC, objNetwork strPrinterUNC = "\\serverName\printe "\\serverName\printerShareName" rShareName" Set objNetwork = CreateObject("WScript.Network") objNetwork.AddWindowsPrinterConnection objNetwork.AddWindowsPri nterConnection strPrinterUNC objNetwork.SetDefaultPrinter strPrinterUNC objNetwork.SetDefaultPrinter This might work, but what if the printer has an error or the server the printer is attached to is down? Your users might receive an annoying error like on the picture below and may start to wonder whether you are actually the right person for the job.

Of course it’s not necessarily your fault that the printer is not online, but such errors typically cause the users who don’t bother a lot about IT to think that the world is falling apart and we don’t want our users to think so. We want them to be relaxed and have them go and make them self a cop of coffee while they wait for the printer to be back online. The above script can easely be amended a bit to come up with a lot friendlier error message if the printer is not available.

On Error Resume Next objNetwork.AddWindowsPrinterConnection objNetwork.AddWindowsP rinterConnection strPrinterUNC objNetwork.SetDefaultPrinter objNetwork.SetDefaultPri nter strPrinterUNC If Err.Number 0 Then MsgBox "An error occured during mapping of the default printer: " & Err.Description End If  On Error GoTo 0 This is still the same script in terms of mapping the printer, but now we have specified that we want the script to continue even if it runs into an error. We have done so by writing On Error Resume Next before the code we expect can fail. Furthermore we have put an If condition that will be triggered in case of an error, that is if Err.Number differs from 0, wich is the default number returned if the script runs without problems and everything goes as we expect (i.e. hope for). Finally we have the On Error GoTo 0, which tells the script to stop the error handling and continue without error handling throughout the remaining of the script.

Now, if the printer is unavailable and we have taken the effort to write our own error message, we will receive an error like:

It looks a little cleaner and may cause less confusion for the users on your network. It’s possible to write your own comments about the error and mix it with the actual error description returned from the script host. This is done by using the Err.Description as shown in the previous script snippet. You can also use Err.Number if you want to return the error code and work with this to return different messages to the users depending of the specific error number. Something like:

If Err.Number = xxx Then Do something smart here… Else If Err.Number = yyy Then Do something even smarter here… End If 

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 er ror 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.

Error Handling Rules Overview VBScript offers some limited facilities to help your manage runtime errors. Here is a summary of rules that will help you to properly manage runtime errors in your VBScript code: 1. The "On Error Resume Next" statement can be used to turn on the error handling flag. 2. The "On Error GoTo 0" statement can be used to turn off the error handling flag. 3. User defined procedures have their own error handling flags. This means that each user defined procedure should be have its own "On Error Resume Next" or "On Error GoTo 0" statement to turn on or off its own error handling flag. 4. By default, error handling flags of all user defined procedures and the main code are turned off. 5. By default, the host environment provides a built-in object called "Err" to hold runtime error information. 6. When a runtime error occurs, the host environment will set values to properties of the "Err" object and raise a runtime error. 7. When a runtime error is raised and the current error handling flag is on, the host environment will continue to execute the next statement. 8. With the error handling flag turned on, you can inspect "Err" object properties to determine how to handle the error and continue your code execution.

9. When a runtime error is raised in a procedure and the current error handling flag is off, the host environment will stop executing the procedure, transfer execution control to the calling code, and raise the same runtime error in the calling code. 10. When a runtime error is raised in the main code and the current error handling flag is off, the host environment will stop executing the main code, and take some additional steps. 11. When Internet Explorer (IE) gets a runtime error with the error handling flag turned off, it will display small dialog box, if its script debug option is turned on. 12. When Windows Script Host (WSH) gets a runtime error with the error handling flag turned off, it will print out an error message. Conclusions: •

Runtime errors will be managed by the host environment, if you don't manage them.

•

"On Error Resume Next" turns on the error handling flag, which causes the host environment to continue executing the next statement after raising a runtime error.

•

"On Error GoTo 0" turns off the error handling flag, which causes the host environment to stop executing the current procedure after raising a runtime error.

•

The "Err" object is built-in object representing the last runtime error.

•

"Err.Number > 0" can be used to see if a runtime error has occurred or not.

•

"Err.Clear()" method can be used to clear the "Err" object.

•

"Err.Raise()" method can be used to raise your own runtime errors.