Second Error Handler Doesn't Work

[JayRenn]

I have a section of code that evaluates the state of several check boxes. The first group I am calling "Email Controls", the second is "Item Controls". Each check box has its own individual name.

In the first group there will always be at least 5 controls - Email_D through Email_H. There may be additional controls. This code snippet shows one extra called Email_I. The line "On Error GoTo No_More_Email_Controls" works correctly when it hits the non-existent Email_I control.

So far, so good.

The second group will always have Email_6 through Email_10. The code shows two possible extras: Email_11 and Email_12. When the interpreter hits the test line for Email_11 it generates error 438 and pops up a message box - which tells me that the line "On Error GoTo No_More_Item_Controls" either isn't working, or is being ignored. I've tried a dozen different fixes from around the 'net, but it refuses to handle the error.

I have noticed that if I get rid of the first error handler (and the code that would generate it) the second error handler works fine. I tried setting the error handler to "GoTo 0" right before I set the second error handler, but that didn't help. What step am I missing?


----- Code -----

Please Login or Register  to view this content.

[shg]

There are three ways that the code in an error handler could come to execute: To have execution transferred as the result of an error, to have execution transferred as the result of an Application.Goto statement, and to fall into it in straight-line execution.

• If you arrive via an error, VBA considers the code to be in the error handler, and

o You cannot change the error handler in the error handler, and On Error Resume Next has no effect

o It cannot handle its own errors

o Resume statements behave as documented

• If you arrive via straight-line execution or a GoTo statement, VBA considers the code to be about halfway into an error handler:

o You can change the active error handler

o An error will renter the top of the error handler (the first time; see above)

o The behavior of Resume statements, which cause run-time errors outside of an error handler, behave in a different way:

 All executions of a Resume statement will reenter the error handler, perhaps resulting in an endless loop, so none should appear

 The first execution of a Resume Next statement will reenter the error handler, and the second execution will fall through. I can’t think of a case where this is desirable behavior.

Here’s a typical example:

Please Login or Register  to view this content.

In general, for end of procedure error handling,

• The first error handler should be preceded with an Exit Sub|Function

• Each error handler should end with a Resume statement (Resume, Resume Next, or Resume statement#)

• The error handler should never be the target of Application.Goto

[JayRenn]

Thanks SHG! That makes sense.