Using error control in a vbscript to recover from odd errors

In my last installment, Finding HP Printers using PCL6 Drivers with WMI, I gave you a handy script snippet that showed you how to pull the names of the printer drivers for your printers shared on a print server. In the script I used a few pieces of code that may not be familiar to everyone. In the next few installments we’ll explain better what the script does and how it does it—so hopefully you can begin applying the knowledge elsewhere…

The script was basically (line numbers included as a reference):

1. On Error Resume Next
2.  strComputer = “.”
3. Set objWMIService = GetObject(”winmgmts:\\” & strComputer & “\root\cimv2″)
4. Set colItems = objWMIService.ExecQuery(”Select * from Win32_PrinterDriver”,,48)
5. For Each objItem in colItems
6.     Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
7.     Wscript.Echo “DataFile: ” & objItem.DataFile
8.     Wscript.Echo “DriverPath: ” & objItem.DriverPath
9.     Wscript.Echo “Name: ” & objItem.Name
10.   Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
11.   WScript.Echo “_________________” & vbcrlf
12. Next

In line 1, the statement On Error Resume Next may be new to you. This statement basically keeps your script from breaking completely and not completing due to a minor error. The down side of this is that if your code isn’t tightly checking for errors it will continue to run with potentially bad logic and cause quite a bit of havoc on your network. IMHO, you should try to avoid it where ever possible. In this case it wasn’t possible because there were to many unknowns.

As an FYI, The brother to On Error Resume Next is On Error Goto 0, basically this turns error checking back on. So, if you need to use it in an area where you’re not certain a piece of code may or may not encounter an error from time to time it’s best to turn error checking back on after that piece of code completes its work.

Consider this example code that has errors:

Wscript.echo “Stepping through ‘Y’ from 1 to “ & X
On Error Resume Next
Wscript.echoo “Error in this line!!!!”
Wscript.echo “Did this line print?”

Of course, if you run this it won’t complete, it will display something similar to:

Stepping through ‘Y’ from 1 to
C:\www.websystemsadministration.com\errorcontrol.vbs(2, 1) Microsoft VBScript runtime error: Object doesn’t support this property or method: ‘Wscript.echoo’ 

This tells us there is an error in line 2 of the script… and gives us a slight hint (sometimes) of what the error is. In this case, we’ve user a function of the Wscript object that does not exist, echoo. Of course we want to know about that. But suppose we didn’t? Well, this would stop vbscript from complaining:

Wscript.echo “Stepping through ‘Y’ from 1 to “ & X
On Error Resume Next
Wscript.echoo “Error in this line!!!!”
Wscript.echo “Did this line print?”

Now it displays:

Stepping through ‘Y’ from 1 to
Did this line print? 

Notice it skipped the line with an error and went to the next line? To turn error checking back on we just adjust the script this way—but we add a final line with an error to see if it breaks on an error:

Wscript.echo “Stepping through ‘Y’ from 1 to ” & X
On Error Resume Next
Wscript.echoo “Error in this line!!!!”
On Error Goto 0
Wscript.echo “Did this line print?”
Wscript.echoo “What about this new line?!?!” 

Still the same output, but now you see an error… because we turned error checking back on!

Next installment, I’ll  Explain the Set and the Getobject section of the code.

Extra credit: There is a “soft error” in the script that would never cause the script to break, but cause you TONS of debugging time. Did you find it in the code … or the output? Post a comment and I’ll let you know what I think it is in the comments section in a few days!