The only time you need the On Error GoTo 0 line is if there's a matched On Error... line.

if you don't set "on error goto 0", the previous error handler (ie "on error resume next") will still be effective even after the method (sub or function) ends which might leads to undesirable effects.

Eric, I think you missed my point.  These particular On Error Goto 0 are all followed by Exit Sub.
That means there is no  On Error Resume Next.

check your MyUnchangedSub sub.

You find a "on error resume next" statement just before the Close. If you don't have a "on error goto 0" statement somewhere after, all errors will just be silently skipped.

I agree that if you don't have any "on error do something", it is useless to have the "on error goto 0" (but I don't think it hurts to have it).

It's a protection mechanism.

It doesn't hurt to have it, but forces error handling after any sub is called.  This way if someone adds on error resume next somewhere else in the sub, it'll clean itself up at the end of the procedure.

Essentially forces the program to behave with normal error handling.  

Martin, I agree with your statement but would extend it as follows:

The only time you need the On Error GoTo 0 line is if there's a matched On Error... line in the same subroutine.

But that still does not quite get to the heart of my question.

I originally thought that the following subroutine would have no affect whatsoever on any higher level program.

It turns out that the scope of any On Error is indeed limited to the active program.
Nonetheless, there is a subtlety that can have an affect on a higher program.

The subtlety is that every On Error statement does an automatic Err.Clear.
In other words I should stick with "if its not broke don't fix it"

Does  everyone  agree with this statement?
<on error goto 0:End sub> is equivalent to <err.clear:End Sub>

I do not intend to actually make such a change because it "looks weird". Nonetheless, I believe the abovestatement is true.

Sub test030()
Call NoAffect
MsgBox err
Stop

End Sub

Sub NoAffect()
On error resume next
debug.print 1/0
if  rnd() > .5 then on error goto 0
end sub
 
 

 
This comment was Irrelevant to this question
 

All I can say is that I've looked at thousands (perhaps tens of thousands) of macros and I don't believe any of them had a stand-alone On Error GoTo 0 line.

and can someone tell me how to fix the title of this question?  

Use the "Edit Question" link in the original question post of this question, and adjust the title as desired.

---

»bp

martin said "All I can say is that I've looked at thousands (perhaps tens of thousands) of macros and I don't believe any of them had a stand-alone On Error GoTo 0 line. "

I agree.  It looked weird when I saw it, but it is code that I wrote at least 15 years ago.  I probably will go ahead and delete it even though that violates the "if its not broken" rule 

and can someone tell me how to fix the title of this question?

Report it as a bug. In case you don't know how to do that...

1. Click your 'My account' logo
2. Click 'FEEDBACK' near the bottom
3. Click 'Report a bug'
4. Select the '2022, Q2: General EE Defect Reports' file
5. Follow the instructions

<on error goto 0:End sub> is equivalent to <err.clear:End Sub>

No.

Err.Clear will just clear the error, but leaves the error handling in place.

On Error GoTo 0 removes the custom error handling.  

On Error Goto  0:
This instruction reset the error handler to the default one in the current function.
Calling it right before the end of the function has no effects since error handlers are local to the function they're implemented in.
In other words, the top level function's error handler is not reseted by the sub level functio, so you can safelly remove it.

The following illustrate this:

Public Sub test()
On Error GoTo Error
    subTest
    Dim i As Integer
    i = i / 0
Exit Sub
Error:
    Debug.Print "divide by zero detected."
End Sub

Public Sub subTest()
On Error GoTo 0
End Sub

Select allOpen in new window

False,

The on Error Goto 0 statement clear the error object (as you mentionned earlyer).
The only way for the if statement to be true is the Level2 function ignore any error.

Sub Main()
   Call Level2
   If Err <> 0 Then MsgBox "err=" & Err
End Sub

Sub Level2()
On Error Resume Next
    Dim i As Integer
    i = 5 / 0
End Sub

Select allOpen in new window

But,this is pure garbage programming and must be forbidden at all costs, or if you have the bad luck to see it somewhere, fix it immediatly.

Honestly, I don't see the point of arging about of bad practices, even if that's doable.

I agree so we will stop arguing.  

-------------------------------
Recap of original question
Does [On Error Goto 0 : End Sub] function exactly like [end sub]
-------------------------------
While reviewing some VBA code that I wrote 15 years ago, I noticed something annoying.
A handful of those old subroutines looked like this for no obvious reason.

Function xyz()
' ----- Big Chunk of code with many <On Error resume Next> statements 
' ----- all of which were correctly terminated with <On Error goto 0" 
' ----- But the Chunk of code was followed with a standalone <On Error GoTo 0>
' ----- which was immediately followed by End Function
On error GoTo 0
End Function

Select allOpen in new window

I  am 100% sure those GoTo 0 lines are effectively useless, so I am deleting them from my code.
 
Can anybody think of a functional reason that I shouldn't delete the useless statement? (I am not interested in discussing "cosmetic reasons").
--------------------------------
The following "Summary Correct Answer"  applies to End Function | Exit Function | End Sub | Exit Sub
--------------------------------
 
Every Expert said approximately the same thing, but Fabrice came the closest to giving the correct answer:
 
" There is no functional difference, but code with useless statements should be avoided as it provides confusion."
 
The correct answer is
   Line980:  On Error Goto 0
   Line990:  End Function
Is almost exactly like
   Line990:  End Function
 
 
But if the code is not following VBA "best practices" there are some quirky differences that might cause problems in very rare circumstances.
 
I examined my code carefully and decided to delete the superfluous On Error GoTo 0 statements.
--------------------------------
The following is a way too  long winded "More Correct Answer" .
--------------------------------
 
When <On Error GoTo 0> appears to be superfluous  it can almost always be removed.
But every <On Error> statement automatically invokes Err.Clear.. In pathologically bad code deleting such a superfluous line might make a higher level program misfire, but it is very unlikely to happen in real life. Don't worry about it.
 
But, if you do want to worry about it, then the appropriate best practice is:

1. Match every <On Error Resume Next> with  a corresponding <On Error GoTo 0>, and keep the code path between them as small as possible.
2. Do not put in standalone On Error statements that serve no purpose.

 
Example 1 where the <On Error GoTo 0> is "best practice" because it matches line800: Line980 should not be removed.
Sub DeleteFileAndOtherStartup(fullpath as string)
Call OtherStartUpStuff
Line800: On Error Resume Next
kill fullpath
Line980:  On Error GoTo 0
Line990:  End Function
 
Example 2 where the <On Error GoTo 0 is superfluous and Line980 should be removed.
Sub DeleteFileAndOtherStartup(fullpath as string)
on error resume next
kill fullpath
On Error GoTo 0
Call OtherStartUpStuff
Line980:  <On Error GoTo 0
Line990:  End Function
 
Example 3 where the <On Error GoTo 0 is  probably superfluous.  Somebody (but not me)  might argue that Line980 should be left in place  because it is paired with line100. .
Option Explicit
 
Sub AnySub(fullpath As String)
line100: On Error GoTo err_show
    ' ----- there is a bunch of  unrelated code that I am not showing--
    On Error Resume Next
    Kill fullpath
    On Error GoTo err_show
    ' ----- and some more  unrelated code that I am not showing--
exit_routine:
Line980:  On Error GoTo 0
Line990:  Exit Function
 
err_show: ' This routine is not expected to ever throw an error, so we use Err_Show.
    MsgBox Err & "(" & Error & ") encountered " & IIf(Erl <> 0, " at or after Erl=" & Erl, "")
    Resume exit_routine
End Function