Re: how to continue running the script
- From: "Joe Earnest" <jearnest3-SPAM@xxxxxxxxxxxxx>
- Date: Sun, 3 Apr 2005 07:05:15 -0600
Hi,
"Lynn" <MarryLynn@xxxxxxxxx> wrote in message
news:O5G72hAOFHA.2384@xxxxxxxxxxxxxxxxxxxxxxx
>i have placed On Error Resume Next and it moves on to execute the next few
> functions which depends on the first function and fails.
> how can i program it such that when it encounters an error it will move on
> to grap the next computer name from the file and not moving on to execute
> the following few functions?
>
>
>
> "Brian Wolven" <brian.wolven@xxxxxxxxxxxxxx> wrote in message
> news:et3wNJ$NFHA.2728@xxxxxxxxxxxxxxxxxxxxxxx
>> Lynn wrote:
>> > Hi,
>> > I have a while loop which grap computer names from a data file to see
>> > if
>> > they are online.
>> > How can i write a code for a senario whereby the script will move on to
> the
>> > next computer name in the list if error is encountered?
>> > currently it just stops there when error is encountered.
>>
>> On Error Resume Next
>>
>> Of course, it might be better to try to catch/handle/fix those errors. ;)
>
Error-trapping is scope-specific. If you run your loop at the level of the
global code, calling a procedure which in turn calls your other procedures,
you can force any procedure error to jump back to the next line in the
global code, instead of the next line in the procedure. To accomplish this,
simply place your On Error Resume Next statement in the global code, and
remove any On Error Resume Next statements from the procedure code. Be sure
to clear the Err property in the global code. Try the following simple
scripts:
-----
on error resume next
testFn
wscript.echo "Back in the global script." _
& vbCr & "Err = " & err
function testFn()
err.raise 1
wscript.echo "This is the next procedure line."
err.clear
end function
-----
-----
on error resume next
testFn
wscript.echo "Back in the global script." _
& vbCr & "Err = " & err
function testFn()
on error resume next
err.raise 1
wscript.echo "This is the next procedure line."
err.clear
end function
-----
As I noted, the Err object is implemented in scope-specific manner, but its
scoped implementation is entirely different from variable scoping. The MS
CHM file documentation on the ERR object is simply wrong in a couple of
regards, and insufficient on the issue of scope. FWIW, here's a standard
schpeal that I put together a few years back from some very informative old
posts by Michael Harris and Torgeir Bakken, and my own experimentation.
(Second time this week!)
-----
The MS VBS CHM file 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 Goto 0 does 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.
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.
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 0, 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.
VBS error handling lacks call stack tracing, but that aspect can be added
with privately implemented procedures or classes. Michael Harris has posted
some elegant script creating an error call stack. 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 as simple as pseudo-labels in a do-looped select case block, so that
implementation of script arguments that call those procedures in different
order, and the script reruns itself with the appropriate argument and quits,
when a specific error is encountered.
One especially touchy 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
.
- Follow-Ups:
- Re: how to continue running the script
- From: Lynn
- Re: how to continue running the script
- References:
- how to continue running the script
- From: Lynn
- Re: how to continue running the script
- From: Brian Wolven
- Re: how to continue running the script
- From: Lynn
- how to continue running the script
- Prev by Date: Re: How do we execute or modify this link in asp server side?
- Next by Date: reload the vbscript itself within a vbscript
- Previous by thread: Re: how to continue running the script
- Next by thread: Re: how to continue running the script
- Index(es):
Relevant Pages
|
