中断类模块与中断未处理的错误(VB6 错误捕获,IDE 中的选项设置) [英] Break in Class Module vs. Break on Unhandled Errors (VB6 Error Trapping, Options Setting in IDE)

查看:11
本文介绍了中断类模块与中断未处理的错误(VB6 错误捕获,IDE 中的选项设置)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

基本上,我试图了解 Visual Basic 6.0 IDE 中出现在以下路径下的中断类模块"和中断未处理的错误"之间的区别:

Basically, I'm trying to understand the difference between the "Break in Class Module" and "Break on Unhandled Errors" that appear in the Visual Basic 6.0 IDE under the following path:

Tools --> Options --> General --> Error Trapping

三个选项似乎是:

  • 打破所有错误
  • 打破课堂模块
  • 打破未处理的错误

现在,显然,根据 MSDN,第二个选项(中断类模块)实际上只是意味着中断类模块中未处理的错误".此外,这个选项似乎是默认设置的(即:我认为它是开箱即用的).

Now, apparently, according to MSDN, the second option (Break in Class Module) really just means "Break on Unhandled Errors in Class Modules". Also, this option appears to be set by default (ie: I think its set to this out of the box).

我想弄清楚的是,如果我选择了第二个选项,我是否可以免费获得第三个选项(中断未处理的错误)?在那,它是否默认包含在类模块范围之外的所有场景中?提醒一下,我当前活动的项目中没有任何类模块.我有 .bas 模块.另外,是否有可能通过 Class Mdules,它们也可能指的是普通的 .bas 模块?(这是我的第二个子问题).

What I am trying to figure out is, if I have the second option selected, do I get the third option (Break on Unhandled Errors) for free? In that, does it come included by default for all scenarios outside of the Class Module spectrum? To advise, I don't have any Class Modules in my currently active project. I have .bas modules though. Also, is it possible that by Class Mdules they may be referring to normal .bas Modules as well? (this is my second sub-question).

基本上,我只是想让设置确保在 exe 发布后不会有任何意外.我希望在开发时显示尽可能多的错误,而在发布模式下不显示.通常,我的表单上有两种类型的 On Error Resume Next 没有明确的错误处理,它们如下:

Basically, I just want the setting to ensure there won't be any surprises once the exe is released. I want as many errors to display as possible while I am developing, and non to be displayed when in release mode. Normally, I have two types of On Error Resume Next on my forms where there isn't explicit error handling, they are as follows:

出错时恢复下一个'需要出错时继续下一步'不需要

On Error Resume Next ' REQUIRED On Error Resume Next ' NOT REQUIRED

所需的是,检查数组是否有任何长度,如果对其 UBound 的调用出错,则意味着它没有长度,如果它返回 0 或更大的值,则它确实有长度(因此,存在).即使在我开发时,这些类型的错误语句也需要保持活动状态.但是,在我开发过程中,NOT REQUIRED 不应该保持活动状态,因此我将它们全部注释掉以确保我捕获所有存在的错误.

The required ones are things like, checking to see if an array has any length, if a call to its UBound errors out, that means it has no length, if it returns a value 0 or more, then it does have length (and therefore, exists). These types of Error Statements need to remain active even while I am developing. However, the NOT REQUIRED ones shouldn't remain active while I am developing, so I have them all commented out to ensure that I catch all the errors that exist.

一旦我准备好发布 exe,我就按 CTRL+H 来查找所有出现的:

Once I am ready to release the exe, I do a CTRL+H to find all occurrences of:

'在出错时继续下一步'不需要

'On Error Resume Next ' NOT REQUIRED

(你可能已经注意到它们被注释掉了)......并将它们替换为:

(You may have noticed they are commented out)... And replace them with:

出错时继续下一步'不需要

On Error Resume Next ' NOT REQUIRED

... 未注释的版本,以便在发布模式下,如果有任何遗留错误,它们不会显示给用户.

... The uncommented version, so that in release mode, if there are any leftover errors, they do not show to users.

有关 MSDN 对三个选项的描述的更多信息(我已经阅读了两次但仍然没有找到足够的内容),您可以访问以下链接:

For more on the description by MSDN on the three options (which I've read twice and still don't find adequate) you can visit the following link:

http://webcache.googleusercontent.com/search?q=cache:yUQZZK2n2IYJ:support.microsoft.com/kb/129876&hl=en&lr=lang_en%7Clang_tr&gl=au&tbs=lr:lang_1en%7Clang_1tr&prmd=imvns&strip=1

如果您愿意自愿参与,我也很想听听您的想法(这将是我的试探性/完全可选的第三个子问题,即您对回退错误处理技术的想法).

I’m also interested in hearing your thoughts if you feel like volunteering them (and this would be my tentative/totally optional third sub-question, that being, your thoughts on fall-back error handling techniques).

总结一下,前两个问题是,如果我们选择选项 2,我们是否会将选项 3 包含在所有非课堂场景中?而且,当他们使用术语类模块"时,他们是否也可能指的是 .bas 模块?(因为 .bad 模块实际上只是在启动期间在后台预先实例化的类模块).

Just to summarize, the first two questions were, do we get option 3 included in all non-class scenarios if we choose option 2? And, is it possible that when they use the term "Class Module" they may be referring to .bas Modules as well? (Since a .bad Module is really just a class module that is pre-instantiated in the background during start-up).

谢谢.

推荐答案

我将从第一个选项开始.中断所有错误只会禁用您的错误处理程序.当您在放入错误处理程序后尝试调试时,这很有用,因为处理程序本身可能有错误,或者当错误在容器层次结构中冒泡时您可能无法跟踪错误发生的位置(错误是't 在过程中处理尝试在调用过程中查找处理程序,如果您试图找到有问题的代码行,这可能会令人困惑).

I'll start with the first option. Break on all errors simply disables your error handlers. This is useful when you are attempting to debug after you've put in error handlers, because you can have errors in the handlers themselves, or you can lose track of where the error happened when the error bubbles up the containership heirarchy (errors that aren't handled in a procedure attempt to find a handler in a calling procedure, which can be confusing if you're trying to find the offending line of code).

接下来,如果存在导致错误的代码行,则中断未处理的错误实际上不会在类模块中中断.如果您设置了此选项,并且您在类中调用了一个方法,并且该方法的代码行中存在错误,那么您将在客户端中具有该方法调用的行上中断.

Next, break on unhandled errors doesn't actually break in a class module if there is a line of code causing an error in there. If you have this option set, and you call a method in a class, and there's an error in the line of code in the method, you'll break on the line in your client that has the method call.

中断类模块转到类中出现错误的代码行.对此的警告是,如果您使用的是 ActiveX EXE,则控制设置在其项目中,而不是在客户端项目中.也就是说,您可以中断客户端项目中设置的所有错误,中断 ActiveX EXE 项目中设置的未处理错误,并且不会中断类模块,因为您正在处理两个单独的进程.

Break in class module goes to the line of code in the class that has the error. A caveat to this is that if you are working with an ActiveX EXE, the controlling setting is in its project rather than in the client project. That is, you can have break on all errors set in your client project, and break on unhandled errors set in your ActiveX EXE project, and you won't break in the class module because you are working with two separate processes.

我个人更喜欢在类模块中将其设置为中断,因为它可以让我以最大的精度深入到错误的位置.不过,这是在我开始做错误处理程序之前;在那一点上,我通常会在所有三个方面都反弹,这取决于我试图稳定什么.

I prefer personally to leave it set on break in class module, because it lets me drill down to the site of the error with greatest precision. This is before I start doing error handlers, though; at that point I generally bounce around all three, depending on what I'm trying to stabilize.

最后,我不建议永远使用 On Error Resume Next,除非是在内联错误处理的上下文中.

Finally, I do NOT recommend EVER using On Error Resume Next except in the context of inline error handling.

这篇关于中断类模块与中断未处理的错误(VB6 错误捕获,IDE 中的选项设置)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆