类模块中断，未处理错误断开（VB6错误陷阱，IDE中的选项设置） [英] Break in Class Module vs. Break on Unhandled Errors (VB6 Error Trapping, Options Setting in IDE)
问题描述
基本上，我试图理解Visual Basic 6.0 IDE中出现的类别模块中断和未处理错误中断之间的区别，其路径如下：
工具 - >选项 - >一般 - >错误捕获
这三个选项似乎是：
- 打破所有错误
- 打破类模块
- 错误
现在，根据MSDN，第二个选项只是意味着打破类模块中的未处理错误。此外，此选项似乎默认设置（即：我认为其设置为这个开箱）。
我想要找出的是，如果我有第二个选项选择，我得到第三个选项（打破未处理的错误）是免费的？那么，对于Class Module频谱之外的所有场景，它是否默认包括在内？为了建议，我在我当前活动的项目中没有任何类模块。我有.bas模块。此外，是否有可能通过类Mdules他们可能是指正常的.bas模块？ （这是我的第二个子问题）。
基本上，我只是想要的设置，以确保不会有任何惊喜一旦exe发布。我想要尽可能多的错误显示尽可能在我正在开发，而不是在释放模式下显示。通常，我有两种类型的On Error Resume Next在我没有显式错误处理的表单上，它们如下：
在错误恢复下一步'REQUIRED
On Error Resume Next'NOT REQUIRED
所需的是类似的东西，检查数组是否有任何长度，如果调用其UBound错误out ，这意味着它没有长度，如果它返回一个值0或更多，那么它有长度（因此，存在）。这些类型的错误语句需要保持活动，即使我正在开发。但是，在我正在开发的时候，NOT REQUIRED不应该保持活动状态，所以我将它们全部注释掉，以确保捕获所有存在的错误。
一次我准备释放exe，我做一个CTRL + H找到所有出现：
'错误恢复下一步'不需要
（您可能已经注意到他们已注释掉）...并将其替换为：
所以在发布模式下，如果有任何剩余错误，它们不会显示给用户。
有关MSDN的说明的更多关于三个选项ve read two and still do not find enough），您可以访问以下链接：
我也有兴趣听取你的想法，如果你觉得自愿他们（这将是我的暂定/完全可选第三-question，这是你对后退错误处理技术的想法）。
只是为了总结，前两个问题是，我们得到选项3包括在所有如果我们选择选项2？而且，当他们使用术语类模块时，它们可能也指的是.bas模块？ （因为.bad模块只是一个在启动时在后台实例化的类模块）。
谢谢。
我将从第一个选项开始。打破所有错误只是禁用您的错误处理程序。这是有用的，当你尝试调试后，你已经把错误处理程序，因为你可以在处理程序本身有错误，或者你可以失去跟踪错误发生时，错误发生在容器的层次层次结构（错误在尝试在调用过程中找到一个处理程序的过程中处理它，如果你试图找到令人讨厌的代码行，可能会混淆）。
下一步，如果有一行代码导致错误，在未处理的错误中断开实际上不会在类模块中中断。如果你设置了这个选项，并且在类中调用了一个方法，并且方法中的代码行中有错误，你就会在具有方法调用的客户端中断线。
在类模块中的中断到具有错误的类中的代码行。需要注意的是，如果您使用ActiveX EXE，则控制设置位于其项目中，而不是客户端项目中。也就是说，您可以对客户端项目中设置的所有错误进行中断，并打破在ActiveX EXE项目中设置的未处理错误，并且不会打断类模块，因为您正在使用两个单独的进程。
我更喜欢亲自在类模块中将它设置为break，因为它允许我以最大的精度深入到错误的网站。这是在我开始做错误处理程序之前，虽然;
最后，我不推荐使用On Error Resume Next，除了在内联错误处理的上下文。
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
The three options appear to be:
- Break on All Errors
- Break in Class Module
- Break on Unhandled Errors
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).
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).
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
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.
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.
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:
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).
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).
Thank you.
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.
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.
Finally, I do NOT recommend EVER using On Error Resume Next except in the context of inline error handling.
这篇关于类模块中断，未处理错误断开（VB6错误陷阱，IDE中的选项设置）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
