right you are Doug! I'm just used to coming from a VB-like database interpreted language, and it's equivalent of "on error goto 0" *does not* reset the error indications! I never thought, since there existed an err.clear method, that this could ever happen! so I figured it was worth a mention.
thanks. Chip -----Original Message----- From: Doug Geoffray [mailto:[email protected]] Sent: Tuesday, April 20, 2010 10:27 AM To: [email protected] Subject: Re: to VBScript programmers Chip, Yes, this is indeed true. But just to show another alternative <smile>, you could do the following: on error resume next <statement which might have an error> lastErr = err.number on error goto 0 if lastErr <> 0 then ' do something about error end if This way you don't need two on error goto 0 commands or possibly miss a path of turning it off which I've done before. Doug 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 > > >
