Sometimes, you want to trap scripting errors before anyone notices. Good error handling is the key.
Graceful Error Handling
Sometimes, you want to trap scripting errors before anyone notices. Good error handling is the key.
- By Chris Brooke
- May 01, 2000
I remember a certain math teacher I had in high school.
She was so understanding. Whenever I made a mistake on
my homework, she would lean all 275 pounds on my desk,
put those big, bloodshot eyes right in front of mine,
and say:
“You Got It WRONG!”
Ever since then, I’ve tried to ensure that if I
do make a mistake, I fix it before anyone else notices.
As NT administrators, we must remain vigilant about errors.
We perform backups, install hardware RAID 5 arrays in
our mission-critical servers, and even implement expensive
single-IP clustering solutions to make sure that if—heaven
forbid—anything does go wrong, no one will notice
(we hope).
It’s important to be equally conscientious regarding
potential errors in your scripts. Exactly how idiot-proof
we can make our scripts depends on the particular idiot
(ourselves) running them. (I’ve always maintained
that as soon as you make something idiot-proof, someone
comes along and builds a better idiot!) As scripts become
more complex, the potential for errors increases greatly.
It’s vital to trap these errors as they happen and
deal with them gracefully. The alternative is the see-no-evil,
hear-no-evil approach—close your eyes, wait for something
to happen, and then blame the user!
To Err is Human, to Forgive… Err.Clear
There are several ways to handle errors in your scripts.
For instance, in “Supercharge Your
Scripts”
(October 1999), I put an “If…Then” section
at the beginning of the script to ensure that the user
had entered the correct command-line arguments. That’s
error handling! That kind of error handling is preventative;
whereas, here I’m focusing on corrective error handling.
Whenever an unexpected condition arises during script
execution, all information pertaining to that error is
passed automatically to the Err object. The Err object
is an intrinsic object, meaning it’s always there
when you run a script—just like the WScript object
I discussed last issue. In other words, you don’t
have to create an instance of it (via CreateObject) in
order to use it. Its Properties include Err.Number and
Err.Description, and it also has two Methods, Err.Clear
and Err.Raise. Err.Clear clears all the error properties,
and Err.Raise generates a runtime error in your script.
You can use this to simulate errors, so that you can properly
code to handle them.
The Details
The first requirement for using the Err object is to
include “On Error Resume Next” at the beginning
of your script. This enables error handling. Without this
line, any errors in your script cause execution to stop
and an error message to be displayed. With this line included,
execution continues with the line following the one that
caused the error. You can then place code in your script
(if necessary) to help it recover.
‘FakeError.vbs
Dim strX
On Error Resume Next
strX="Hello World!"
strX=strX+1 ‘Try to add a number to a string value.
Bad juju!
If Err.Number<>0 Then
WScript.Echo
& "You can’t do that! You caused
Error "
& Cstr(Err.Number) & " "
& Err.Description
Err.Clear
End If
WScript.Echo strX
WScript.Quit
This forces an error by trying to add an integer value
to a string. Figure 1 shows the output from this script.
As you can see in Figure 1, strX remained “Hello
World!” when we printed it at the end. The important
thing to note is that the script executed to the very
end. Without the error handling, it would have shut down
in line five.
|
Figure 1. With error handling,
the script still executes to the end. |
The Real World
Apply what you’ve just learned and write a script
for an all-too-common administrative task.
Situation: You’ve
just fired an employee for cause, and you want to force
a password change for every user in the domain, just in
case this guy tries to break in using someone else’s
password. There are many ways to do this. Here, you accomplish
this task using Software Artisans’ SA-Admin product,
which we’ve used in the past for user management.
‘ResetPW.vbs
Option Explicit
Dim objUser, iCount, iNum
Set objUser=CreateObject("SoftArtisans.User")
objUser.GetDomainController "MyDomain", True
iCount=objUser.UserCount
iNum=0
Do
‘Cycle through users
objUser.User=objUser.UserItem(iNum)
‘Resetting the change PW option as we
go
objUser.MustChangePW=True iNum=iNum+1
Loop Until iNum=iCount
Set objUser=Nothing ‘Kill the
object
WScript.Quit
As you can see, this is a rather simple script that cycles
through every user in the specified domain and sets the
MustChangePW property to true. This forces everyone to
change his or her password at the next logon (and is much
faster than using User Mangler—oops, I mean “Manager”—to
do it).
Unfortunately, there are at least two big problems with
this script. First, the domain name is hard-wired in the
code. Not very flexible, is it? Second, if the PDC is
unreachable, what happens to the script execution? Rather
than look for more bugs, use what you’ve learned
about error handling to write a better script.
‘ResetPW.vbs
‘‘**** Section 1 ****
Option Explicit
On Error Resume Next
Dim objArgs, objUser, iCount, iNum, strDomain
Set objArgs=Wscript.Arguments
‘**** Section 2 ****
‘Make sure they only pass one argument
If objArgs.Count<>1 Then
ShowUsage()
End If
‘**** Section 3 ****
strDomain=objArgs.Item(0)
Set objUser=CreateObject("SoftArtisans.User")
objUser.GetDomainController strDomain, True
If Err.Number<>0 Then ‘Can’t
find PDC
WScript.Echo
"Invalid Domain Controller or
PDC not available>"
WScript.Echo "Please check domain name."
ShowUsage()
End If
‘**** Section 4 ****
iNum=0
iCount=objUser.UserCount
Do
‘Cycle through users
objUser.User=objUser.UserItem(iNum)
‘Resetting the change PW option as we
go
objUser.MustChangePW=True
iNum=iNum+1
Loop Until iNum=iCount
Set objUser=Nothing
Set objArgs=Nothing
Wscript.Quit
Sub ShowUsage()
WScript.Echo "Please Enter the Domain
name."
WScript.Echo
"Example: cscript ResetPW.vbs
MyDomain"
WScript.Quit
End Sub
Section 2 shows that you don’t always have to use
the Err object to check for bad data. You can trap errors
without it. Here, a simple If…Then statement ensures
that only one argument (the domain name, one hopes) was
passed to the script. Just in case the user made an error
typing in the domain name, Section 3 makes sure it’s
valid and reachable. As long as Err.Number=0, the SoftArtisans.User
component was able to find the domain controller. If that’s
the case, the script is free to cycle through all the
accounts, resetting the MustChangePW Property to True.
In the ResetPW.vbs script, you’re merely trapping
the errors and gracefully exiting the script—an end
result similar to what would have happened if you had
left well enough alone. However, now that you’ve
trapped the errors, do something else with them. Your
homework is to modify ResetPW.vbs to allow user input
to correct both incorrectly entered arguments and invalid/unreachable
domains. I’ll have my version for you next month
in Error Handling, Part Deux. And don’t worry—I
won’t embarrass you in front of the class.