VBA Err Not Reset: Is Exit Sub Enough?

• ⚠️ Exit Sub does not automatically clear the Err object in VBA.
• 🤖 Err.Number stays set until you clear it with Err.Clear.
• 🔄 Errors can spread across procedures if not handled right.
• 🛠️ On Error Resume Next stops errors from interrupting but doesn’t clear them.
• 🚨 Not using structured error handling can cause wrong results or hide problems.

VBA (Visual Basic for Applications) is an important scripting language for making macros and automated tasks in Microsoft Office applications. Even after many years, many developers still miss important points about how VBA error handling — especially the Err object — works with things like Exit Sub. This article looks at if Exit Sub in VBA clears Err, how error handling really works, and what you need to do to make your code run safely and as you expect.

What Microsoft Documentation Says About VBA Err and Exit Sub

The official documentation from Microsoft about the Err object and On Error statement gives important information for managing errors that happen when code runs in VBA. The Err object keeps track of details about runtime errors, like the error number and description. And the On Error statement helps you catch these errors and choose what to do.

But neither document says that just leaving a procedure — whether using Exit Sub, Exit Function, or Exit Property — will clear the Err object. This lack of clear info makes many think that calling Exit Sub "clears" the error, but it doesn't.

According to Microsoft:

"Once an error has been handled, you can clear it using the Err.Clear method."

This clearly tells the developer they must clear Err themselves. And Exit Sub does not do this for you.

Real-World Behavior: Err Stays Set After Exit Sub

To show that the Err object stays set even after a procedure ends, let’s look at a simple example:

Sub TestExitSub()
    On Error Resume Next
    Dim x As Integer
    x = 1 / 0  ' This triggers Division by Zero error (Error 11)

    Exit Sub
End Sub

And then check the value of Err.Number with another sub after running the first:

Sub TestIfErrStillSet()
    Debug.Print "Err.Number: "; Err.Number
End Sub

If you run TestExitSub and then TestIfErrStillSet, you will see a result you might not expect, but it's right:

Err.Number: 11

Even though the code left TestExitSub cleanly using Exit Sub, the Err value is still in memory. This means Exit Sub does not automatically call Err.Clear.

This behavior is very important in bigger applications where procedures call other procedures, or where your code needs to know if there were errors before. Unhandled or uncleared errors can cause big problems when trying to find bugs.

Why Not Clearing Errors Is Dangerous

Leaving Err uncleared can cause confusing, wrong, or even bad things to happen in your VBA projects.

❌ Wrong Error Messages

If later code checks Err.Number thinking there's only a new error, it might mistake an old error for a new one.

🔍 Confusing Debugging Info

When errors stay set and aren't cleared, it can be hard to find where a problem really started, especially in code with many parts that work together.

🔁 Bugs Spreading Unexpectedly

The Err object stays set for all procedures in the same program thread. So, any code that needs a clear error state might break or act strangely.

🧩 Unpredictable User Experience

Users working with forms, buttons, or other Office parts might see the same strange issues again and again if errors stay hidden between actions.

In short, not using Err.Clear makes systems break easily. The fix? Clear and always-used ways to handle errors.

Looking at VBA Error Handling Approaches

Let’s break down the main ways to handle errors in VBA and see how they affect the Err object.

1. The Silent Exit (Used with On Error Resume Next)

Sub SkipsError()
    On Error Resume Next
    Dim result As Integer
    result = 5 / 0  ' Division by zero
    Exit Sub
End Sub

Here, On Error Resume Next stops the code from stopping, and Exit Sub lets the procedure finish without issue. But the error still sits in Err.Number.

If you run another subroutine later, or if your code's path changes based on Err.Number, this old error state can cause problems.

2. Structured Error Handler (Using On Error GoTo)

It's best to use a set way to handle errors:

Sub StructuredHandler()
    On Error GoTo ErrHandler
    Dim result As Integer
    result = 5 / 0

    Exit Sub

ErrHandler:
    Debug.Print "Caught Error " & Err.Number & ": " & Err.Description
    Err.Clear
    Resume Next
End Sub

This way has benefits like:

• Clearly finding where the error is
• Good ways to record or report errors
• Makes sure Err gets cleared with Err.Clear

How to Handle VBA Errors Right

To make sure VBAs Err object works as expected and does not let errors spread to other code blocks, use patterns like this:

Sub MyRoutine()
    On Error GoTo HandleError

    ' Main logic
    Dim x As Integer
    x = 1 / 0  ' Forces division error

    Exit Sub

HandleError:
    Debug.Print "Caught error in MyRoutine: " & Err.Number & " - " & Err.Description
    Err.Clear
    Resume Next
End Sub

Main Rules:

• Put code that might have errors inside a TryBlock ... ErrorHandler structure.
• Always use Err.Clear after you deal with an error, mainly before you call other subs.
• Use Resume Next with care — it starts the code again on the line right after the one that caused the error, not from the beginning.

When You Can Use Exit Sub Without Err.Clear

There are a few times, in certain situations, where you can use Exit Sub without calling Err.Clear by hand.

🔹 When You Might Not Clear Err:

• You know for sure no error happened.
• The procedure has nothing risky (like reading files, dividing, or calling outside programs).
• The code finishes normally and leaves safely before doing risky things.

🚫 But It's Still Better to Clear

Even when it seems safe, not clearing the Err object can cause unexpected issues later. It's a good habit to put Err.Clear at the end of procedures that used On Error Resume Next, no matter if they ran into an error or not.

When Procedures Call Each Other: Errors You Can See

VBA's Err is global for the current program task. This is extra important when one procedure calls another.

Here’s an example to show this:

Sub ParentProcedure()
    On Error Resume Next
    Err.Raise 91  ' Object variable not set
    ChildProcedure
End Sub

Sub ChildProcedure()
    Debug.Print "Child sees error: " & Err.Number
End Sub

Output:

Child sees error: 91

Why? Because ChildProcedure gets the Err state that wasn't cleared. If ChildProcedure has code that needs a clear error state, that code might give wrong results or cause problems you don't want.

👉 Always clear Err before making function or procedure calls that need to check for errors!

Common Mistakes With VBA Err

To handle VBA errors well, avoid these common mistakes:

1. ✅ Thinking Exit Sub clears errors. It doesn't.
2. ❌ Using On Error Resume Next but not checking for errors after.
3. ❌ Not clearing Err before calling another function.
4. ❌ Thinking Err.Description being empty means no error — always check Err.Number instead.
5. 🔁 Having hidden errors repeat in loops or repeated steps.
6. 🤐 Hiding big errors without writing them down.

Good error handling is not just about stopping programs from crashing. It's about being clear for both users and developers.

Tips for Debugging and Good Coding

Help your VBA team do well with these habits:

• ✔️ Always use Debug.Print for info while you're coding.
• ✔️ Include timestamps and Err.Number in logs.
• ✔️ Use Err.Clear before and after code sections that might cause errors.
• ✔️ Don't put On Error Resume Next inside many levels of code.
• ✔️ Use easy-to-understand error labels (ErrHandler, Cleanup, HandleError) to make code easier to read.
• ✔️ Think about making helper functions to check for Err.Number and clear it automatically.

By using these habits, you’ll avoid one of the most annoying debugging problems in VBA — finding a 'ghost' error that came from code run a long time ago.

Key Points

• ✅ Exit Sub does not clear the Err object in VBA — use Err.Clear to do that by hand.
• ⚠️ Using On Error Resume Next can stop errors from interrupting, but they stay active and can be misunderstood later.
• 🔁 Errors are global per thread; errors not handled can be passed to procedures that get called.
• 🧰 Structured error handling makes sure errors are cleared, code is easy to read, and it's simple to keep up over time.
• 🔎 Make error handling and checking clear and a planned part of how you write code.

Taking error handling seriously in your VBA code is not just for catching bugs. It's key for writing code that works well and you can use again in Excel, Word, Access, and other places.

More Places to Learn

• Microsoft: On Error Statement
• Microsoft: Err Object Reference
• Devsolus guides on VBA good ways to code and fix problems
• Professional Excel Development (book) — for making very strong VBA systems

Citations:

Microsoft. (n.d.). On Error Statement.
Microsoft. (n.d.). Err Object.