Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
in this vbscript the second Err.Clear is required or not as a part of optimization.
Set WshShell = CreateObject("WScript.Shell")
strSpoRootKey = "HKLM\SOFTWARE\"
strKey = RootKey & "tcc\Operation\" & Version & "\Location"
strPath = wshShell.RegRead(strKey)
If Err Then
Err.Clear //first Err.clear
RootKey = "HKLM\SOFTWARE\Wow6432Node"
strKey = RootKey & "tcc\Operation\" & Version & "\Location"
strPath = wshShell.RegRead(strKey)
If Err Then
Err.Clear // second Err.clear
strErr = strErr & ": " & Version & ": " & strKey & ":error("
End If
End If
Shall we remove the second Err.Clear from code
The purpose of calling Err.Clear to explicitly clear the Err object after you have trapped and handled an error. MSDN suggests that this is especially useful when you are using deferred error handling with On Error Resume Next. This suggests that you really should be calling Err.Clear after you have handled the error that was detected, whatever that means for your particular application.
You didn't really provide enough of your code to suggest the kind of error handing routines that you're using. For example, if you have On Error Resume Next in your code above the block that you posted, and/or what you're doing with strErr to actually handle the error. Does your script end at the end of the posted section? If so, you're probably in the clear removing the second Err.Clear, since it'll be impossible for another error be raised anyway during the script's course of execution.
Regardless, I'm going to take the easy way out and suggest that you do the same: there is absolutely no reason to "optimize" this code by removing any Err.Clear statements. I promise that statement is not bottlenecking the execution speed of your script. Unless you are experiencing problems with your error handling routines (like trapping the same error twice or failing to trap an error because it has been cleared prematurely), there's little reason to worry about "extra" Err.Clear statements.
yes second Err.Clear should be downside once error
handled properly other wise it carry forward to next stage
so things will change to
If Err Then
strErr = strErr & ": " & Version & ": " & strKey & ":error("
Err.Clear // second Err.clear
End If
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.