I've seen that one as well. My favorite though is what happens if you
have an error in an If or Do inside an On Error Resume Next block.
I've explained this before, but it's worth repeating...
Consider the following code block. Do not run this!
option explicit
dim oSomething : set oSomething = createObject("Scripting.dictionary")
on error resume next
if oSomethin .count <> 0 then
speak "This dictionary came into existance with content. How
can that be?"
end if
dim i : i = 1
do while oSomethin.count < 10
oSomething.add "i, "random value"
i = i +1
loop
on error goto 0
There may be errors besides what I'm about to describe above; I did
not test this block myself just now. But...
The first If contains a misspelling of "something," so it contains a
reference to an invalid variable. Because we're in an "on error
resume next" block, the VBScript interpreter dutifully goes to the next
line to skip the error. The next line happens to be inside the If block.
This means, in effect, that an error in an If statement makes the
statement always True.
With that in mind, we move down to the Do line, which contains the
same error. It also has the same effect: The error causes control to
move to the next line, i.e., the first line in the loop. Because the
error will never be fixed by anything inside the loop, what we have
here is an infinite loop!
So as I often say, when coding inside an On Error Resume Next block,
watch your step...
On Tue, Apr 20, 2010 at 10:10:18AM -0400, Allison and Chip Orange wrote:
Hi all,
just a tip for VBScript scripters which was biting me even though I didn't
know it. it is, in all of my scripts, I have some form of the following
structure:
on error resume next
<statement which might have an error>
on error goto 0
if err.number <> 0 then
' do something about error
end if
it turns out that "on error goto 0" clears the error condition, so testing
on the err.number property afterwards is useless apparently.
so, it looks like the correct way to do this is:
on error resume next
<statement which might have an error>
if err.number <> 0 then
on error goto 0
' do something about error
end if
on error goto 0
Aaron, this was my test to see if loadClassInformation succeeded or not, so
in the cases where it did not, because of some odd condition such as the
application was still initializing, it looks to me like I wouldn't have
known it, and so would have thought loadClassInformation was sometimes
failing without an error. How it failed on the second or third use of a
constant I can't explain, but I don't think there's a problem with
loadClassInformation any more.
Thanks to Gary Metzler for his help in tracing this down, and for working
with me on this error because he could reliably reproduce it.
Chip
--
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:[email protected] http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
