在类debugging中引发的错误，就像在属性调用中引发一样
我（不幸的是）在Excel 2000 VBA中开发应用程序。 我相信我发现在自定义类属性，函数或子debugging中引发的任何错误，就好像在调用属性的VBA代码中引发错误一样。 也就是说，VBEdebugging器不会把我带到发生错误的Class属性的位置，而是在第一次input属性的位置（例如，从Module Sub或Function中）。这使得开发任何超过最浅的OO Excel 2000 VBA代码，因为我必须逐行逐行地通过每个Class方法来发现导致错误的指令。
我是否错过了一些东西，或者这是一个我必须在Excel 2000中处理的已知错误？ 这是在2003年还是2007年？
示例代码：
''''''''''''''' '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 对于Office 2003，当debugging器configuration为中断未处理的错误（默认configuration）时，您将得到此行为。
如果你想让它在Err.Raise行中断开，你需要configuration它以打破所有错误（工具/选项/常规/错误捕获/中断所有错误）。
我相信这是相同的Office 2000，但没有副本检查。
这个页面是VBAerror handling的一个非常好的资源：
- Microsoft Access，VBA和Visual Basic 6的error handling和debugging技巧和技巧
这个“function”在Excel 2003中是一样的，如果在2007年有所不同，我会感到惊讶。
在Excel 2010中同样如此 – 这正是我遇到这种行为的地方。
引用Chip Pearson的网站 ：
绝对没有理由使用Break In Class Module以外的错误陷印设置。
他描述的错误模式之间的区别：
在testing和运行代码时，您有三种错误捕获模式。 首先是打破所有错误。 如果发生任何错误，这将导致debugging器打开，无论您在代码中可能有哪些On Error处理。 第二个选项是Break On Unhandled Errors。 如果错误不是由现有的On Error指令处理的话，这将导致debugging器打开。 这是最常用的选项，是默认设置。 第三个选项，Break In Class Module是最重要和最less使用的。 这不是默认的错误捕获模式，所以您必须手动设置它。
Break In Class模块是最重要的，因为它会导致debugging器在实际导致问题的对象模块中断开代码行。 “分类分类”模块设置位于“工具”菜单上的“选项”对话框中。 它位于“选项”对话框的“常规”选项卡上，如下所示。