ThreeWave Using Break In Class Module

This page describes using the Break In Class Module setting in your VBA Code.
ShortFadeBar

Error Handling

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.

Break In Class Module

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,

    UserForm1.Show
    

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()
        ' Force an error for illustration.
        Debug.Print 1 / 0
    End Sub
    

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.

ShortFadeBar
LastUpdate This page last updated: 27-Oct-2012.

-->