One of the more frequent questions I come across relates to the situation where an active and enabled error handler section handles the first error as expected but then fails to handle any subsequent errors. (An enabled error handler is one that is turned on by an On Error statement and an active error handler is an enabled handler that is in the process of handling an error.)
Here’s the explanation (it’s a little long, but bear with me!):
The On Error statement is the heart of VBA error-handling. Without an On Error statement, any run-time error that occurs will display an error message, and code execution will stop.
There are 4 distinct On Error options:
- On Error Resume Next
- On Error GoTo some_label/line_number
- On Error Goto 0
- On Error Goto -1
This is the simplest error handling option but also the most dangerous and most often misused. It ensures that when a run-time error occurs, control simply goes to the statement immediately following the statement where the error occurred, and execution continues from that point. There is no message to alert the user as to the fact that an error has occurred, or to what it might be. A typical good use of this structure is when there is a predictable error that you want to override – often assigning an object that may or may not exist to a variable. For example, when testing for the existence of a worksheet in a workbook, you can loop through all the worksheets checking the name of each one, or you can employ an On Error Resume Next statement like this:
Dim ws as Worksheet
On Error Resume Next
Set ws = activeworkbook.worksheets("some name")
If not ws is nothing then
' do stuff
The danger of this is if you do not remember to reset error handling (by either simply disabling it with On Error Goto 0 or enabling an error handler – see below) all further errors in your code will be suppressed, which can make problems very hard to locate and debug – you may not even notice them until your code is already in real use, which is never a good thing!
I frequently see people simply put On Error Resume Next at the top of their procedures when they can’t figure out why an error is occurring – THIS IS NOT A GOOD IDEA!! It’s the code equivalent of hearing a strange noise coming from your car engine and simply turning the radio up. Sure, you can’t hear the noise anymore, but at some point something very bad is probably going to happen.
On Error GoTo some_label/line_number
Enables the error-handling routine that starts at the specified line label or number. If a run-time error occurs, control passes to that specified line, making the error handler active. (The specified line must be in the same procedure as the On Error statement, or a compile-time error will occur).
Disables any enabled error handler, including On Error Resume Next, in the current procedure. (It doesn’t specify line 0 as the start of the error-handling code, even if the procedure contains a line numbered 0!) Without an On Error GoTo 0 statement, an error handler is automatically disabled when a procedure is exited normally.
Resets the active error status (exception) to Nothing without disabling any currently enabled error handler. You should very rarely see or use this. If you find yourself using this, you should probably rethink the structure of your code. (Like Goto 0, it does not specify line -1 as the start of the error-handling code, even if the procedure contains a line numbered -1). Without an On Error GoTo -1 statement, the active error is automatically reset when a procedure is exited normally.
Now that we’ve covered that, why does the original problem arise? (I’ll wait while you go back and read the start to refresh your memory as to what the problem actually was)
Essentially there are two key concepts in error handling in VBA:
- whether an error handler is enabled (we covered this above)
- whether there is an active error condition – this can be a little surprising.
When an error occurs, an active error condition is set (what they call an exception in current VB). If there is no error handler, you see a message and code stops. That’s pretty simple.
Where it gets interesting is if there is an enabled error handler. If there is, it becomes active until the active error condition is reset. The only ways to reset an active error condition and deactivate an error handler are via a Resume, Exit Sub, Exit Function, or Exit Property statement, or via an On Error Goto -1 statement. Note: On Error Goto 0 will deactivate an error handler, but will not reset the active error condition so you cannot follow it with another On Error statement (other than an On Error Goto -1 to clear the error) and hope to handle further errors. Hence, the following approach will not work:
On Error GoTo err_handle
On Error GoTo 0
On Error Resume Next
MsgBox “You will never see this message”
While the current procedure’s error handler is active, or there is an active error condition, no further errors can be handled by that procedure. If another error occurs during this period, control returns to the calling procedure, if any, or an error message is produced and processing stops.
Typically in the questions I see, there is no Resume statement – there’s either a GoTo statement or the error handling label/line number is just the start of another section of code, or precedes a looping statement (Next, Wend, Loop for example). None of these scenarios will work because the error condition is not reset, and so the error handler is still active, and cannot handle further errors.
Sometimes I see people try to use Err.Clear to reset the error condition but in actual fact this merely clears the properties of the Err object, which is always available and holds information about the last error to occur. It is not the same as the active error condition and cannot be used to reset it.
An error-handling routine is not a Sub procedure or a Function procedure. It is simply a section of code marked by a line label or a line number.
To prevent error-handling code from running when no error has occurred, place an Exit Sub, Exit Function, or Exit Property statement immediately before the error-handling routine.
I plan to add some code snippets here soon as a test of what you just read – your task will be to figure out what will happen in each of them before actually running the code! 😉
If you find yourself using On Error Goto -1 a lot (or at all), you need to stop and rethink what you are doing! I have never, ever, seen well-written code that required it and have never used it myself in actual production code.