I show a script and its behavior. I ask questions below.

A:\>type try3.vbs
set WshShell = CreateObject("WScript.Shell")

on error resume next
' err.clear ' This call seems superfluous
result = WshShell.Run("fred", 10, true):
if err then
    ' on error goto 0' at this point destroys or zeroes err object
    wscript.stderr.writeline("Failed to run fred"   & vbnewline & _
    "err.description = """ & err.description & """" & vbnewline & _
    "err.helpcontext = """ & err.helpcontext & """" & vbnewline & _
    "err.helpfile    = """ & err.helpfile    & """" & vbnewline & _
    "err.number      = """ & err & """ (&H" & hex(err) & ")" & vbnewline & _
    "err.source      = """ & err.source      & """" & vbnewline & _
    "result          = """ & cint(result) & """" )
end if
on error goto 0
WshShell.Run("fred"):

A:\>cscript try3.vbs
Microsoft (R) Windows Script Host Version 5.1 for Windows
Copyright (C) Microsoft Corporation 1996-1999. All rights reserved.

Failed to run fred
err.description = ""
err.helpcontext = "0"
err.helpfile    = ""
err.number      = "-2147024894" (&H80070002)
err.source      = ""
result          = "0"
A:\try3.vbs(17, 1) The system cannot find the file specified.

A:\>

Am I right in thinking that err.clear is only useful where error
handling is involved with procedures and functions? It seems
useless in a flat script.

"on error goto 0" is not documented as writing to err. Should it?

I contrast "A:\try3.vbs(17, 1) The system cannot find the file specified."
and my &H80070002. wscript.scriptfullname produces "A:\try3.vbs". Is the
information decoded as "(17, 1)" available. I recognise 2 as "file not
found"; how is 80070002 decoded as "The system cannot find the file
specified."?  
--
Walter Briscoe

Question #1
Am I right in thinking that err.clear is only useful where error
handling is involved with procedures and functions? It seems
useless in a flat script.

==> err.clear has as much use in a "flat" script as anywhere else.  There are plenty of cases where
one might trap an error, take an alternate action, and proceed.  Of course leaving "On Error Resume
Next" on all the time isn't a good idea (unless you plan on checking for an error after every line
of code.  A common practice is to leave error trapping off until you reach point where you expect a
potential error that will either be fatal or needs alternate handling.  I you handle the error and
proceed you would either err.clear (if the code proceeds through a series of actions that are
error-prone but recoverable) or turn error handling off with "On Error GoTo 0" which implicitly
clears the err object.

Question #2
"on error goto 0" is not documented as writing to err. Should it?

==> "On Error GoTo 0" doesn't write to anything.  Unhandled script errors (meaning not handled by
your code) are passed to the host.  If the host is WScript.exe the error message is displayed in a
dialog box.  If the host is CScript the error is written to the console but I _think_ it's written
to stdout, not stderr (too lazy to test - which one is it Mr.Whalen?)...

Question #3
I contrast "A:\try3.vbs(17, 1) The system cannot find the file specified."
and my &H80070002. wscript.scriptfullname produces "A:\try3.vbs". Is the
information decoded as "(17, 1)" available. I recognise 2 as "file not
found"; how is 80070002 decoded as "The system cannot find the file
specified."?

===> All unhandled errors throwwn by the script engines and handled by the host are COM errors (the
engine a ActiveX scripting engines) returned as an HRESULT.  Here are a couple of links to help take
the mystery out of an 0x80070002 error code (clue#1 - the 8 means the high bit is on so the HRESULT
indicates an error, clue#2 - 7 is the facilty code for a Win32 error)...

Return Types: HRESULT and SCODE
http://msdn.microsoft.com/library/books/inole/S10F2.HTM

HRESULT
http://msdn.microsoft.com/library/specs/s1d153.htm

microsoft.public.scripting.wsh, Michael Harris

[snip]

I think the following demonstrates that it does.
16:49:04.   try.vbs
' Demonstration that "on error goto 0" writes to err
wscript.echo "At start err.number = " & cint(err.number)
wscript.echo "Setting  err.number = " & 5
err.number = 5
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Adding error-handling"
on error resume next
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Setting  err.number = " & 5
err.number = 5
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Nomore error-handling"
on error goto 0
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Repeating the code above using raise rather than
assignment"
wscript.echo "At start err.number = " & cint(err.number)
wscript.echo "Adding error-handling"
on error resume next
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Setting  err.number = " & 5
err.raise 5
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Nomore error-handling"
on error goto 0
wscript.echo "And so   err.number = " & cint(err.number)

C:\wfb>cscript try.vbs
Microsoft (R) Windows Script Host Version 5.1 for Windows
Copyright (C) Microsoft Corporation 1996-1999. All rights reserved.

At start err.number = 0
Setting  err.number = 5
And so   err.number = 5
Adding error-handling
And so   err.number = 0
Setting  err.number = 5
And so   err.number = 5
Nomore error-handling
And so   err.number = 0
Repeating the code above using raise rather than assignment
At start err.number = 0
Adding error-handling
And so   err.number = 0
Setting  err.number = 5
And so   err.number = 5
Nomore error-handling
And so   err.number = 0

C:\wfb>

I think it is stderr as the message is not redirectable in a W95 DOS
box.

Those documents are useful. Is the method used to translate 80070002 to
"The system cannot find the file specified." available?

Re-inventing wheels is unprofitable.
--
Walter Briscoe

I'm not sure you've proved your point.  In your script, there are no unhandled errors to start with.
With no error trapping in effect (either by default or by an explicit On Error GoTo 0), assigning
err.number a value is *not* the same as an err.raise of the same value.  The only place where you
actually raise an error, you have error handling enabled, so the error isn't "unhandled".

In the script, nothing ever goes to stderr.  All of the script output is via WScript.Echo which all
goes to stdout.  In ran your script on NT4 as

cscript ...\try.vbs 1>stdout.txt 2>stderr.txt

and everything went to stdout.txt.

I ran my own test script that actually generates an unhandled error (a one-liner of "a = 1/0" to
crash with divide by zero).  With the same redirection of stdout and stderr, the error message
(written by cscript.exe itself, not the script engine or the script) went to stderr.

As for translating an error like 80070002 to a text error description, I don't know of any
scriptable tool to do that.  VStudio comes with the errlook.exe utility to do that, but even then if
the error is generated by a COM component, there's no guarantee that even errlook.exe will recognize
it.  Couple that with the fact that the facility codes are not necessarily unique.  8004xxxx error
codes are common among COM components where several components may use 8004 so it doesn't uniquely
identify the context for interpreting the xxxx portion.  For example, two totally unrelated COM
components (A and B) can both raise error 800403f7 with totally different meanings.  In that case,
you need to know which component raised the error and look it up in it's documentation what it means
it's context.

--
Michael Harris
MVP Scripting

microsoft.public.scripting.wsh, Michael Harris

[snip]

I think the following demonstrates that it does.
16:49:04.   try.vbs
' Demonstration that "on error goto 0" writes to err
wscript.echo "At start err.number = " & cint(err.number)
wscript.echo "Setting  err.number = " & 5
err.number = 5
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Adding error-handling"
on error resume next
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Setting  err.number = " & 5
err.number = 5
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Nomore error-handling"
on error goto 0
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Repeating the code above using raise rather than
assignment"
wscript.echo "At start err.number = " & cint(err.number)
wscript.echo "Adding error-handling"
on error resume next
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Setting  err.number = " & 5
err.raise 5
wscript.echo "And so   err.number = " & cint(err.number)
wscript.echo "Nomore error-handling"
on error goto 0
wscript.echo "And so   err.number = " & cint(err.number)

C:\wfb>cscript try.vbs
Microsoft (R) Windows Script Host Version 5.1 for Windows
Copyright (C) Microsoft Corporation 1996-1999. All rights reserved.

At start err.number = 0
Setting  err.number = 5
And so   err.number = 5
Adding error-handling
And so   err.number = 0
Setting  err.number = 5
And so   err.number = 5
Nomore error-handling
And so   err.number = 0
Repeating the code above using raise rather than assignment
At start err.number = 0
Adding error-handling
And so   err.number = 0
Setting  err.number = 5
And so   err.number = 5
Nomore error-handling
And so   err.number = 0

C:\wfb>

I think it is stderr as the message is not redirectable in a W95 DOS
box.

Those documents are useful. Is the method used to translate 80070002 to
"The system cannot find the file specified." available?

Re-inventing wheels is unprofitable.
--
Walter Briscoe

microsoft.public.scripting.wsh, Michael Harris

Your initial response is
Question #2
"on error goto 0" is not documented as writing to err. Should it?

==> "On Error GoTo 0" doesn't write to anything.  Unhandled script errors (meaning not handled by
your code) are passed to the host.  If the host is WScript.exe the error
message is displayed in a
dialog box.  If the host is CScript the error is written to the console
but I _think_ it's written
to stdout, not stderr (too lazy to test - which one is it Mr.Whalen?)...

I now think I might have got a better answer had I phrased my question
as '"on error goto 0" is not documented as writing to the err object.
Should it?'

A demonstration of that is
C:\wfb>type try.vbs
' Demonstrate "on error goto 0" overwrites err
err.clear
on error resume next
err.raise 5
wscript.echo "err.number = " & cint(err.number)
wscript.echo "err.number = " & cint(err.number)
on error goto 0
wscript.echo "err.number = " & cint(err.number)

C:\wfb>cscript try.vbs
err.number = 5
err.number = 5
err.number = 0

C:\wfb>

The problem - aside from lack of documentation - with the current
behavior is that any failure in the code which reacts to a failure is
unlikely to be detected.
C:\wfb>type try.vbs
' Demonstrate "on error goto 0" consequence
set sh = createobject("wscript.shell")

' This does not work
on error resume next
sh.run "fred", 10, TRUE ' this fails
on error goto 0
if err then wscript.echo "fred did not start " & hex(err)

' This works
on error resume next
sh.run "fred", 10, TRUE ' this fails
if err then wscript.echo "fred did not start " & hex(err)
on error goto 0

' This shows undetected error
on error resume next
sh.run "fred", 10, TRUE ' this fails
if err then wscript.print "fred did not start " & hex(err)
on error goto 0

' This detects 2nd error but not first
on error resume next
sh.run "fred", 10, TRUE ' this fails
on error goto 0
wscript.print "fred did not start " & hex(err)

C:\wfb>cscript try.vbs
fred did not start 80070002
C:\wfb\try.vbs(26, 1) Microsoft VBScript runtime error: Object doesn't
support this property or method: 'wscript.print'

C:\wfb>
[snip]

That is what I should expect.
It seems that cscript and errlook use the same set of messages. I infer
there is a common component. I take it that finding such a component is
not trivial or you would already have done it. I have yet to acquire
even a superficial understanding of COM.
[snip]
[Your messages are difficult to handle. Some of your line contain about
100 characters. Hence the extra line breaks introduced by my tool when
quoting.]
--
Walter Briscoe

On Error GoTo 0 implicitly clears the Err object.  That fact is not clearly documented anywhere that
I know of at least not in the VBScript documentation.  It _is_ documented that On Error Resume Next
will clear the Err object.  Until very recently, On Error GoTo 0 wasn't even documented for VBScript
at all.

--
Michael Harris
MVP Scripting

microsoft.public.scripting.wsh, Michael Harris

Your initial response is
Question #2
"on error goto 0" is not documented as writing to err. Should it?

==> "On Error GoTo 0" doesn't write to anything.  Unhandled script errors (meaning not handled by
your code) are passed to the host.  If the host is WScript.exe the error
message is displayed in a
dialog box.  If the host is CScript the error is written to the console
but I _think_ it's written
to stdout, not stderr (too lazy to test - which one is it Mr.Whalen?)...

I now think I might have got a better answer had I phrased my question
as '"on error goto 0" is not documented as writing to the err object.
Should it?'

A demonstration of that is
C:\wfb>type try.vbs
' Demonstrate "on error goto 0" overwrites err
err.clear
on error resume next
err.raise 5
wscript.echo "err.number = " & cint(err.number)
wscript.echo "err.number = " & cint(err.number)
on error goto 0
wscript.echo "err.number = " & cint(err.number)

C:\wfb>cscript try.vbs
err.number = 5
err.number = 5
err.number = 0

C:\wfb>

The problem - aside from lack of documentation - with the current
behavior is that any failure in the code which reacts to a failure is
unlikely to be detected.
C:\wfb>type try.vbs
' Demonstrate "on error goto 0" consequence
set sh = createobject("wscript.shell")

' This does not work
on error resume next
sh.run "fred", 10, TRUE ' this fails
on error goto 0
if err then wscript.echo "fred did not start " & hex(err)

' This works
on error resume next
sh.run "fred", 10, TRUE ' this fails
if err then wscript.echo "fred did not start " & hex(err)
on error goto 0

' This shows undetected error
on error resume next
sh.run "fred", 10, TRUE ' this fails
if err then wscript.print "fred did not start " & hex(err)
on error goto 0

' This detects 2nd error but not first
on error resume next
sh.run "fred", 10, TRUE ' this fails
on error goto 0
wscript.print "fred did not start " & hex(err)

C:\wfb>cscript try.vbs
fred did not start 80070002
C:\wfb\try.vbs(26, 1) Microsoft VBScript runtime error: Object doesn't
support this property or method: 'wscript.print'

C:\wfb>
[snip]

That is what I should expect.
It seems that cscript and errlook use the same set of messages. I infer
there is a common component. I take it that finding such a component is
not trivial or you would already have done it. I have yet to acquire
even a superficial understanding of COM.
[snip]
[Your messages are difficult to handle. Some of your line contain about
100 characters. Hence the extra line breaks introduced by my tool when
quoting.]
--
Walter Briscoe

Hi all - thought I'd add a thought or two.

1. Michael - Based on a short analysis, from CScript, script errors get
reported to stderr, and host errors go to stdout. I did not do an exhaustive
analysis, so if you see different behavior, it's likely a case I didn't
check. If you let me know the details, and I can confirm that what you're
seeing is expected.

2. Walter - I'm not sure I understand all of your comments. Basically, "On
Error Resume Next" disables default error handling, and "On Error Goto 0"
re-enables it. While default error handling is disabled, you have to do
everything yourself - detect the error, handle it, and, if you want the
script to continue, clear it. The fact that setting "On Error *" clears the
error is just the VBScript engine setting itself to a known state when the
error handling setting changes.  When you explicitly set "On Error Resume
Next", you are saying that you are either going to handle or ignore every
error that occurs. When you do "On Error Goto 0", you are saying you want
the engine and/or host to handle the error for you. If an error code is
stored when you start "On Error Goto 0", it should not report the error -
whatever went wrong occurred in an area that you specifically marked as
"ignore errors", so it's ignoring the error. It also clears the error - one
of the principals of "On Error Goto 0" is that if an error has occurred, it
has been handled, so the error object should always be clear.

3. Walter - Michael is correct on the 0x8xxxxxxx format - it really does
depend on the control that raised the exception. The format is called an
HRESULT, and you can look up lot's of information on HRESULTs in MSDN. They
look quite cryptic, but it's a concise way of delivering information
quickly. A well written control should also indicate an error message
written in a language that you can read, but not all do. Unfortunately, the
"8007" items often leave out the message - the 7 indicates it's a Win32
error which has been forced into an HRESULT format. 0x80070002 happens to be
"File not found", by the way.

Sorry for the delay - took a brief vacation 8).

Cheers,
  Mike Whalen
  Windows Script Dev

clearly documented anywhere that
that On Error Resume Next
even documented for VBScript
(meaning not handled by

Hi all - thought I'd add a thought or two.

1. Michael - Based on a short analysis, from CScript, script errors get
reported to stderr, and host errors go to stdout. I did not do an exhaustive
analysis, so if you see different behavior, it's likely a case I didn't
check. If you let me know the details, and I can confirm that what you're
seeing is expected.

===> Mike,

I don't get results different from what you describe.  My statement that "nothing ever gets written
to stderr" pertained specifically to the example script that Walter posted.  In that example there
was never any unhandled error, just a lot of WScript.Echo's, so CScript itself never had any error
to report...

BTW - I didn't think Andrew ever let the crew take vacations (or did you have to take him along
;-)...

--
Michael Harris
MVP Scripting

"nothing ever gets written
posted.  In that example there
itself never had any error

That makes sense now... it's amazing how much email accumulates in two
days.... eyes must be tired....

have to take him along

Hee - he doesn't, but luckily, he's not actually my boss 8). (Don't tell my
real boss - he doesn't let us take vacations, either 8).

Mike Whalen
Windows Script Dev

"...(Don't tell my real boss - he doesn't let us take vacations, either 8)..."

You better hope he doesn't lurk in the NGs either ;-)...

--
Michael Harris
MVP Scripting

"nothing ever gets written
posted.  In that example there
itself never had any error

That makes sense now... it's amazing how much email accumulates in two
days.... eyes must be tired....

have to take him along

Hee - he doesn't, but luckily, he's not actually my boss 8). (Don't tell my
real boss - he doesn't let us take vacations, either 8).

Mike Whalen
Windows Script Dev

microsoft.public.scripting.vbscript, Mike Whalen (MS)

I am sorry I was unclear.
"... if you want the script to continue, clear it". Why?

I do not understand the reason for the VBScript engine doing that. It is
not documented and I will try to show it should not. I shall first vary an
example I have already given with a commentary to try to convince you that
the behavior is unhelpful, ought to be changed and can be changed.

C:\wfb>type try.vbs
' Demonstrate "on error goto 0" consequence
set sh = createobject("wscript.shell")
const prog = "fred" ' No such program exists

' 1) This shows undetected error in error handling code
on error resume next ' Handle errors
sh.run prog, 10, TRUE ' this fails
if err then wscript.print prog & " failed (1) " & hex(err) ' Fails quietly
on error goto 0 ' Stop handling errors and - undocumented - clear err.

' 2) I think this ought do work but does not due to undocumented behavior
' Working means - detect error and collapse in a heap due to unhandled ' '
' error. err is overwritten and the incorrect method is not noticed
on error resume next
sh.run prog, 10, TRUE ' this fails
on error goto 0
if err then wscript.print prog & " failed (2) " & hex(err) ' Fails quietly

' 3) This happens to work correctly at the cost of obfuscation
' It will detect any errors in the error handling code - there are none
on error resume next ' Handle errors
sh.run prog, 10, TRUE ' this fails
save_err = err.number
on error goto 0 ' Stop handling errors and - undocumented - clear err.
if save_err then wscript.echo prog & " failed (3) " & hex(save_err)

' 4) This happens to work correctly at the cost of obfuscation
' It detects an error in the error handling code
on error resume next ' Handle errors
sh.run prog, 10, TRUE ' this fails
save_err = err.number
on error goto 0 ' Stop handling errors and - undocumented - clear err.
if save_err then wscript.print prog & " failed (4) " & hex(save_err)

C:\wfb>cscript try.vbs
fred failed (3) 80070002
C:\wfb\try.vbs(34, 18) Microsoft VBScript runtime error: Object doesn't
support this property or method: 'wscript.print'

C:\wfb>

I argue (and hope I have shown) there is an advantage in not clearing the
err object as an undocumented side-affect of 'on error goto 0'

I do not believe that burden should be placed on me. It is difficult to
ensure that error handling code will not itself be erroneous. I can not
resist the Latin tag QUIS CUSTODIET IPSOS CUSTODES (Who guards the guards
themselves). I want to be able to handle errors in the normal program flow
and leave errors in handling code to the default handler. The current
implementation makes it difficult to detect errors in error handling code.

As this is undocumented, I have difficulty in viewing it as a principle.

It seems a pity that HRESULT interpretation methods used to produce default
error messages are not currently exported or are not documented which
amounts to the same thing. e.g.
C:\wfb>type try4.vbs
' Demonstration failure
set foo = createobject("wscript.shell"): foo.run "bar", 10, true

C:\wfb>cscript try4.vbs
C:\wfb\try4.vbs(2, 42) The system cannot find the file specified.

C:\wfb>

What property or method holds "(2, 42)"?
Why is "The system ..." not written to err.description?
I want all the information available to the default handler to be available
to an 'on error resume next' handler.

And I am sorry I hassled you directly.
[snip]
--
Walter Briscoe

I think we have a fundamental difference in how we think error handling
should work. Every piece of code you wrote works exactly as I would expect
it to, regardless of the language. VBScript doesn't have a way to handle
specific errors and let the others fall through to the default handler -
this is what I think you're looking for. As for some of your specific
points:

Because that's what you do. After handling the error, you should decide
whether the script continues or not. Some errors are fatal, some aren't. If
it isn't fatal, you should handle it then and there and clear it so the next
bit of error handling code doesn't detect the same error again. This isn't
written in stone - if it's beneficial to you to do your error handling
another way, then do so.

This works exactly as I would expect it to. For instance, in a C++
try...catch block, once you leave the catch block, the exception information
is gone (unless you stored it somewhere). This is what you are doing by
setting "on error goto 0" - you are ending the catch block. If it isn't
documented that way, I'm sorry, but that's what it does.

Ya but.... who else can we place the burden on? We have only two modes - you
handle errors, or the host and/or engine handles errors. If you tell us you
want to handle errors, then you have to handle all of the errors. Most error
handling code is pretty simple (print a message and quit or continue). If
you have a complicated error handler, then store the information, turn error
handling back on, and proceed. Or, better yet, leave error handling off,
figure out potential errors in your error handler, and handle them
yourself - that way you are completely in control of the flow.

Yes, it is a pity. But, it is a Win32 error, Win32 errors pre-date HRESULTs,
hence Win32 errors get coerced into HRESULTs, and not all
programs/controls/whatever that set Win32 errors will correctly fill in the
description field of the error object. Like Michael Harris pointed out, the
host/engines aren't always the ones setting the error, and they can't
control how other programs do their error reporting.

I'm not sure why we don't have properties for line number and position. I
would agree with you on everything being available, but for some reason it
isn't. I don't really do much work on VBScript itself, so I don't know what
the future holds there, but I recall this being discussed as a possibility
for JScript's error object. Sorry I don't know more about this.

No prob.

Cheers,
  Mike Whalen
  Windows Script Dev