Errors Raised within Class Debug As If Raised at Property Call

I am (unfortunately) developing an application in Excel 2000 VBA. I believe I have discovered that any error raised within a Custom Class property, function, or sub debugs as if the error were raised at the point in the VBA code where the property is called. That is, the VBE debugger does not take me to the point in the Class property where the error occurred, but instead where the property was first entered (from a Module Sub or Function, e.g.) This makes it frustrating to develop anything more than the most shallow OO Excel 2000 VBA code since I have to step line-by-line through every Class method to discover the instructions causing an error.

Am I missing something or is this a known bug I have to deal with in Excel 2000? Has this been fixed in 2003 or 2007?

Example code:

'In Module1:

Public Sub TestSub1()
    Dim testClass As Class1
    Dim testVariant As Variant
    Set testClass = New Class1
    testVariant = testClass.Property1 'Debugger takes me here...
End Sub

' In Class1

Property Get Property1() As Variant
    Err.Raise 666, , "Excel 2000 VBA Sux!" 'But error is actually thrown here.
End Property


For Office 2003 you will get this behaviour when the debugger is configured to break on unhandled errors (the default configuration).

If you want it to break on the Err.Raise line, you need to configure it to break on all errors (Tools/Options/General/Error Trapping/Break on All Errors).

I believe it's the same for Office 2000 but don't have a copy to check.

This page is a very good resource on error handling in VBA:

This "feature" is the same in Excel 2003 and I'd be surprised if it's different in 2007.

The same still holds true in Excel 2010 - that's where I met this behaviour.

To quote Chip Pearson's site:

There is absolutely no reason to use an error trapping setting other than Break In Class Module.

His description of the difference between the error modes:

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.

Need Your Help

ViewPager + Volley lazy load = mess

android android-viewpager lazy-loading android-volley

So basically, i have a RecyclerView within a fragment, set within onCreateView(), also i've put volley request inside onCreateView() that updates the Recycler adapter with new data that is being lazy

How to Absorb a Keypress?

ms-access access-vba keypress

On my form I have an edit control. I have set up a KeyDown event to detect when the user pushes enter, but I also want to detect shift+space so the user can clear the contents of the box.