My automated test is, of course, automated and thus subject to being overzealous. <grin>
My concern with WeatherOrNot, though, was the sheer number of lines in an "on error resume next" block. I did not look at the code myself, but now that I have, I wonder what effect an error in "If xhttp.WaitForResponse(connectionTimeout) = True Then" would have. If an error is triggered somehow in that line, the next line, the GetXMLFeed line, will run. If that's what you expect and prepared for, all is probably well. It's just so non-intuitive to most of us. The first time this business of error-in-If being true bit me, I was rather incredulous. My automated test also counts WeatherOrNot as infinitely dangerous because it contains functions that set "on error resume next" without restoring it. I did that because I think it would often indicate that the author forgot to include an "on error goto 0" line, but there are legitimate occasions to leave it out, and it looks like you may have hit upon some of those. I certainly see some error handling code in there in any case. Glad my analysis was useful. On Thu, Sep 11, 2008 at 11:29:45AM -0400, Michael D. Lawler wrote: Doug, thanks for this excellent message. We have removed On Error from autocomplete and progressindicator and bullet proofed those scripts. We feel that the On Errors in weevent are necessary and safe. The On Errors in the toolkit are also meant to protect calling scripts. I think the On Errors in weather or not are also correct, but will let Aaron comment further on that. We'll be posting updates to the GW scripts soon. At 04:17 PM 9/10/2008, you wrote: >I was prompted to put this message together by today's chain of >messages about various scripts that produce no output and/or seem to >stall forever. > >I've probably said this before, but I'm not sure if I said it here on >this list. > >I would like to urge Window-Eyes scripters that use VBScript to avoid >using "on error resume next" except where there is very good reason to >do so. Here are a few major problems that little command can cause: > >1. If an error occurs in an If statement while an "on error resume >next" is in effect, it will always act True, because "resume next" >means resume execution inside the If part. This is usually exactly >what you do not want. > >2. If an error occurs in a While or other loop condition, it can >cause an infinite loop, because "resume next" means resume execution >inside the loop. > >3. You may put an "on error resume next" line in your code to catch >one type of error, but it will quietly absorb (and mask) any >unexpected type of error imaginable. For example, if you try >protecting yourself from division by 0 when calculating an average, >but you happen to misspell a variable name, you will get the wrong >answer without seeing why. > >When you do use "on error resume next," I recommend the following >precautions: > >1. Run without that line first and make sure to figure out what kinds >of errors might occur there. This is the time to make sure nothing is >misspelled etc. > >2. When you put the "on error resume next" line in, put a corresponding >"on error goto 0" line below it, and as close to the "on error >resume next" as possible. Avoid control flow commands like If, >While, sub and function calls, etc. within that little space between >the two lines. Think of the gap between "on error resume next" and >"on error goto 0" as a 500-foot deep crack in the ground: If you >don't want someone to fall in, keep that thing skinny! > >In case it's useful, I am pasting below the output of a >hastily-written Perl program that attempts to score vbs files on their >use of "on error resume next." Here are the rules it uses first: > > - A score of N means a set of N code lines between "on >error resume next" and "on error goto 0" (not inclusive) was found. > - Comments and blank lines in code don't count. > - A file's score is the highest count found in it. > - A sub, function, or file with an "on error resume next" >that is not turned back off gets an infinite score. > - Infinite scores will be suffixed with "function," "sub," >or "file" to indicate which type of infinity was found. > >I wrote this rather quickly, so pardon any errors in its results. I >did spot-check it though. > >And here's the output, most unprotected lines first, infinite scores >at the top, files scoring 0 omitted entirely. The file names are the >package name, a slash, and the actual file name. > > Infinite (Function): weatherornot/weatherornot.vbs > Infinite (Function): LookupTerm/LookupTerm.vbs > Infinite (Function): HomerSharedObject/HomerSharedObject.vbs > Infinite (Function): ExamineSystem/ExamineSystem.vbs > Infinite (Function): ActivateWindow/ActivateWindow.vbs > 81: progressindicator/ProgressIndicator.vbs > 59: HarvestWindow/HarvestWindow.vbs > 47: CaptureScreen/CaptureScreen.vbs > 46: weevent/weevent.vbs > 38: OperateServices/OperateServices.vbs > 34: CalculateDate/CalculateDate.vbs > 26: IEMax/IEMax.vbs > 20: winamp/winamp.vbs > 19: TerminateProcesses/TerminateProcesses.vbs > 18: RelaunchWindow-eyes/RelaunchWindow-eyes.vbs > 18: CheckLanguage/CheckLanguage.vbs > 16: TrackTime/TrackTime.vbs > 16: SetCheckbox/SetCheckbox.vbs > 16: SelectText/SelectText.vbs > 16: RunAtCursor/RunAtCursor.vbs > 16: RecentPaths/RecentPaths.vbs > 16: PasteSpecialCharacter/PasteSpecialCharacter.vbs > 16: JumpToItem/JumpToItem.vbs > 16: InteractiveJScript/InteractiveJScript.vbs > 16: InstallPackages/InstallPackages.vbs > 16: GoToSpecialFolder/GoToSpecialFolder.vbs > 16: GoToFolder/GoToFolder.vbs > 16: FocusControl/FocusControl.vbs > 16: EvaluateJScript/EvaluateJScript.vbs > 16: DetectShortcutKeys/DetectShortcutKeys.vbs > 16: AppendToClipboard/AppendToClipboard.vbs > 15: gwtoolkit/gwtoolkit.vbs > 15: MicrosoftWordCount/WinwordCount.vbs > 14: autocomplete/autocomplete.vbs > 11: HomerLayout/HomerLayout.vbs > 9: ScriptTemplate/ScriptTemplate.vbs > 9: ReplyToSender/ReplyToSender.vbs > 9: RemapCapsLock/RemapCapsLock.vbs > 9: EdSharp/EdSharp.vbs > 8: WEActions/WEActions.vbs > 8: TogglePunctuation/TogglePunctuation.vbs > 8: SpellIt/SpellIt.vbs > 8: ScriptMenu/ScriptMenu.vbs > 8: ScriptManager/ScriptManager.vbs > 8: RestoreDefaultSets/RestoreDefaultSets.vbs > 8: LearnScripting/LearnScripting.vbs > 8: KillWineyes/KillWineyes.vbs > 8: FileDir/FileDir.vbs > 8: DeleteStrokes/DeleteStrokes.vbs > 8: BeautifyVBScript/BeautifyVBScript.vbs > 6: easycddaextractor/easycddaextractor.vbs > 5: ShutdownNow/ShutdownNow.vbs > 5: RestartNow/RestartNow.vbs > 5: QuerySettings/QuerySettings.vbs > 5: LoadedScripts/LoadedScripts.vbs > 5: ConvertUnits/ConvertUnits.vbs > 4: AlternateMenu/AlternateMenu.vbs > 3: RelaunchWindow-eyes/BootStrap.vbs > >-- >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 -- Michael D. Lawler Voice 260-489-3671 Fax 260-489-2608 Internet mailto:[EMAIL PROTECTED] web http://www.gwmicro.com ftp ftp://ftp.gwmicro.com GW Micro, Inc., Development Liaison and Technical Support Supervisor -- 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
