类调试中引发的错误就像在属性调用中引发的一样

发布于 2024-07-09 16:45:48 字数 724 浏览 9 评论 0原文

我(不幸的是)正在 Excel 2000 VBA 中开发一个应用程序。 我相信我已经发现,在自定义类属性、函数或子调试中引发的任何错误,就好像该错误是在调用该属性的 VBA 代码中引发的。 也就是说,VBE 调试器不会将我带到 Class 属性中发生错误的位置,而是将我带到首次输入该属性的位置(例如,从模块子或函数),这使得开发除最浅的 OO Excel 2000 VBA 代码,因为我必须逐行检查每个类方法以发现导致错误的指令。

我是否遗漏了某些内容,或者这是我必须在 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

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

小耗子 2024-07-16 16:45:48

对于 Office 2003,当调试器配置为在未处理的错误时中断(默认配置)时,您将出现此行为。

如果您希望它在 Err.Raise 行上中断,则需要将其配置为在所有错误上中断(工具/选项/常规/错误捕获/在所有错误上中断)。

我相信 Office 2000 也是如此,但没有副本可供检查。

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.

z祗昰~ 2024-07-16 16:45:48

这个“功能”在 Excel 2003 中是相同的,如果在 2007 中有所不同,我会感到惊讶。

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

一片旧的回忆 2024-07-16 16:45:48

在 Excel 2010 中同样如此 - 这就是我遇到这种行为的地方。

引用 Chip Pearson 的网站

除了中断类模块之外,绝对没有理由使用错误捕获设置。

他对错误模式之间差异的描述:

当您测试和运行代码时,您可以使用三种错误捕获模式。 第一个是“出现所有错误时中断”。 如果发生任何错误,这将导致调试器打开,无论代码中可能有任何错误处理。 第二个选项是“未处理错误时中断”。 如果现有的 On Error 指令未处理错误,这将导致调试器打开。 这是最常用的选项,也是默认设置。 第三个选项“闯入课堂模块”是最重要且最少使用的。 这不是默认的错误捕获模式,因此您必须手动设置。

类模块中的中断是最重要的,因为它将导致调试器中断实际导致问题的对象模块中的代码行。 中断类模块设置位于“工具”菜单上的“选项”对话框中。 它位于“选项”对话框的“常规”选项卡上,如下所示。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文