Using Break In Class Module
This page describes using the Break In Class Module setting in your VBA Code.
When you are testing and running your code, you have three error trapping modes. The first is Break On All Errors. This
will cause the debugger to open if any error occurs, regardless of any On Error handling
you might have in the code. The second option is Break On Unhandled Errors. This will cause the debugger to
open if the error is not handled by an existing On Error directive. This is the most
often used option and is the default setting. The third option, Break In Class Module is the most important
and least used. It is not the default error trapping mode, so you have to set it manually.
The Break In Class Module is the most important because it will cause the debugger to break on the
line of code within an object module that is actually causing the problem. The Break In Class Module setting is
in the Options dialog accessible on the Tools menu. It is on the General tab of the
Options dialog, as shown below.
For our discussion, we will look at a UserForm as the object module. Other object modules include Class modules,
the ThisWorkbook module, and the Sheet modules. A regular code module is not an object module.
If you have your error trapping set to Break On Unhandled Errors and an error occurs within the form's
Initialize method or any method called by Initialize, the debugger will take you to the line
of code that created the object. This creation takes place when you use the Load statement
to load a form into memory, or when you call Show to make the userform visible. (The
Show method will Load the form if it is not already in
memory.) For example,
Clearly, there is nothing wrong with this statement. The error is inside the userform's code, not in the Show method.
If error trapping is set to Break On Unhandled Errors, the debugger will show this line of code as the source of the
error. You could spend a lot of time trying variations of the code to get it to work, but you would continue to get an error.
The Break In Class Module tells the debugger to go inside the object module and flag the line of code that is actually
causing the error. For example, suppose your userform has an Initialize event like the following:
Private Sub UserForm_Initialize()
Debug.Print 1 / 0
If Break In Class Module setting in effect, the debugger would take you to the Debug.Print statement within
the userform's object module, as the cause of the error. If the setting is something else, the debugger would take you to the line where the
form is displayed with the Show method, masking the true cause of the error.
There is absolutely no reason to use an error trapping setting other than Break In Class Module.
||This page last updated: 27-Oct-2012.