Effect of speed on error message

• It makes no sense to compare the speed of correct and incorrect implementation. If your script doesn't fill out its specs without error handling and gets slower when using OERN, you need to choose a different language.
• Since OERN errors are hidden , its scope should be as small as possible. Your sample code smells like using OERN all over the world - a very bad idea. Also: after every risky operation and the corresponding Err.Number check, you need Err.Clear or "On Error GoTo 0".
• In other languages ​​(eg Python) "it is easier to ask forgiveness than permission" ; due to the poor nature of VBScript error handling, you should "watch before jumping" in most cases, and only use OERN when absolutely unavoidable (eg, check for registry keys, deal with possible external resource failures).

Idiom for handling local errors:

Dim gaErr ' global error array
...
Sub SomeSub()
    ...
    OERN
    risky op
    gaErr = Array(Err.Number, Err.Description, ...)
    OEG0
    If gaErr(0) Then
       handle error
    ...
End Sub

      

        
        
        
      

    

If your specs require global error handling:

Dim gaErr
OERN
ret = main()
gaErr = Array(...)
OEG0
If gaErr(0) Then
   some fatal/not locally handled error occured somewhere in your script
   handle it gracefully
Else
   If ret is bad Then
      deal with this
   Else
      ask for more money
   End If
End If
WScript.Quit good/bad

Function main()
  main = ...
End Function

      

        
        
        
      

    

Update comment:

Why is the global OERN evil? Consider:

OERN
(1) Process/change important data
(2) Delete original data - if (1) failed you just destroyed the base of your business

OERN
(1) Process/change important data
(2) If Err.Nunber Then Backup(database, destinatiom)
(3) Continue although the Backup didn't take place, because at least three error were hidden

      

        
        
        
      

    

BTW: your Err.Clear addition is in the wrong place - you will lose information about the error before , you can handle this error.

Update comment #:

Consider this demo script:

' dgeh.vbs - demo global error handling

Option Explicit

' globals
Dim gWAN : Set gWAN = WScript.Arguments.Named
Dim gaErr

Dim iRet
' top-level/global OERN starts here (errors before will abort mercylessly)
On Error Resume Next
 iRet  = main() ' not more than two statements!
 gaErr = Array(Err.Number, Err.Description, Err.Source)
On Error GoTo 0
If gaErr(0) Then
   WScript.Echo "Fatal Error:", Join(gaErr, " * ")
   iRet = 1 ' or choose a better number
Else
   If iRet Then
      WScript.Echo "need one of /good, /bad, or /fatal, Mr. User!"
   Else
      WScript.Echo "all well"
   End If
End If
WScript.Quit iRet

Function main()
  main = 2
  If gWAN.Count = 1 And (gWAN.Exists("good") Or gWAN.Exists("bad") Or gWAN.Exists("fatal")) Then
     readTheDocs
     main = 0
  End If
End Function

Sub readTheDocs()
    WScript.Echo "read Microsoft Docs"
    If gWAN.Exists("fatal") Then
       caTastrophy
    Else
       trySomethingRisky
    End If
End Sub

Sub trySomethingRisky()
  Dim n
  If gWAN.Exists("bad") Then n = 1 / 0
  WScript.Echo "but be skeptical of the text and your interpretation"
End Sub

Sub caTastrophy()
  On Error Resume Next ' simulating the evil global OERN and not checking *each* statement
     WScript.Echo "saving the world"
     saveTheWorld
     WScript.Echo "deleting the now obsolete original"
  On Error GoTo 0
End Sub

      

        
        
        
      

    

for

cscript dgeh.vbs /fatal
read Microsoft Docs
saving the world
deleting the now obsolete original
all well
echo %ERRORLEVEL%
0

      

        
        
        
      

    

As there is no Sub saveTheWorld, you just did error handling, VBScript and everything else is deprecated. You can't even promise to never use the evil global OERN again, because you - and the writers who use it habitually (and by doing so proved that they are paid for their jokes, not their code) are gone. Let's hope the calling process does not accept the ERRORLEVEL value as a license for some further deletions.

for

cscript dgeh.vbs
need one of /good, /bad, or /fatal, Mr. User!
echo %ERRORLEVEL%
2

cscript dgeh.vbs /nix
need one of /good, /bad, or /fatal, Mr. User!

cscript dgeh.vbs /fatal /bad
need one of /good, /bad, or /fatal, Mr. User!

      

        
        
        
      

    

Demonstrate a take-before-go strategy.

for a good case:

cscript dgeh.vbs /good
read Microsoft Docs
but be skeptical of the text and your interpretation
all well
echo %ERRORLEVEL%
0

      

        
        
        
      

    

both messages are displayed (and rightfully so).

and now something completely different:

cscript dgeh.vbs /bad
read Microsoft Docs
Fatal Error: 11 * Division by zero * Microsoft VBScript runtime error
echo %ERRORLEVEL%
1

      

        
        
        
      

    

Please mark the absence of the second message. Division by zero will execute the next line in the active OERN area (store in gaErr) and will not continue blindly / thoughtlessly. A risky operation is in progress (execution of the main () and all its children) (via the gaErr proxy). This honors the rule of "no more than two lines (risky statement and saving eror information) in OERN scope".

The price to pay for such global error handling is that you lose line number information - handling gracefully with error becomes more complex.

But since there is only one OERN in your script (you won't have Sub caTastrophy () in your programs), you can comment it out during development and debugging.

the output from OERN is commented out:

cscript dgeh.vbs /bad
read Microsoft Docs
E:\trials\SoTrials\answers\21901890\vbs\dgeh.vbs(46, 30) Microsoft VBScript runtime error: Division by zero