在类模块中断中断处理错误（VB6错误陷阱，IDE中的选项设置） [英] Break in Class Module vs. Break on Unhandled Errors (VB6 Error Trapping, Options Setting in IDE)
问题描述
基本上，我正在试图了解Visual Basic 6.0 IDE中出现的Break in Class Module和Break in Unhandled Errors之间的区别：
工具 - >选项 - >一般 - >错误陷阱
这三个选项似乎是：
- 打破所有错误
- 在类模块中打破
- 打破未处理错误
显然，根据MSDN，第二个选项只是意味着打破类模块中的未处理错误。此外，该选项似乎默认设置（即：我认为它设置为开箱即用）。
我想要弄清楚的是，如果我有第二个选项，我得到第三个选项（打破未处理的错误）是免费的？那么在Class Module频谱之外的所有场景默认情况下呢？建议，我目前活跃的项目中没有任何类模块。我有.bas模块。另外，是否有可能通过Mdules类可以指代正常的.bas模块？ （这是我的第二个子问题）。
基本上，我只是希望设置确保一旦exe被释放就不会有任何惊喜。我想要在开发时尽可能多地显示错误，并且在发布模式下不显示。通常情况下，我的表单上有两种类型的错误恢复下一步，其中没有明确的错误处理，如下所示：
On Error Resume Next'REQUIRED
错误恢复下一步'不需要
需要的是像检查数组是否有任何长度，如果调用其UBound错误， ，这意味着它没有长度，如果它返回0或更多的值，那么它有长度（因此存在）。这些类型的错误语句需要保持活跃，即使我正在开发中。但是，在开发过程中，不需要的不应该保持活动状态，所以我已经把它们全部注释出来，以确保我捕获了所有存在的错误。
一次我准备释放exe，我做一个CTRL + H查找所有出现的情况：
'错误恢复下一个'不需要
（您可能已经注意到他们被注释掉）...并将其替换为：
在错误恢复下一步'不需要
...未注释的版本，所以在发布模式下，如果有任何剩余的错误，它们不会向用户显示。
有关MSDN上关于三个选项的更多内容ve读了两遍，仍然找不到），您可以访问以下链接：
我也有兴趣听你的想法，如果你觉得自愿参与（这将是我的暂定/完全可选的第三个子问题，也就是你对秋季错误处理技术的想法）总而言之，前两个问题是，如果我们选择选项2，我们是否可以选择所有非类场景中包含的选项3？而且，当他们使用班级模块这个词时，他们可能也是指.bas模块呢？ （因为.bad模块真的只是一个在启动时在后台实例化的类模块）。
谢谢。
我将从第一个选项开始。打破所有错误只会禁用您的错误处理程序。当您尝试在引入错误处理程序后尝试进行调试时，这是非常有用的，因为处理程序本身可能会出现错误，或者当错误发生在集装箱堆垛机上时在程序中尝试处理调用过程中的处理程序，如果您试图找到令人讨厌的代码行，可能会令人困惑）。
下一步如果有一行代码导致错误，那么打破未处理的错误并不会在类模块中中断。如果您设置了此选项，并且您在类中调用了一个方法，并且该方法中的代码行中存在错误，那么您将在客户端中调用该方法的行中断。
类模块中的中断转到具有错误的类中的代码行。要注意的是，如果您正在使用ActiveX EXE，则控制设置位于其项目中，而不是客户端项目中。也就是说，您可以在客户端项目中设置的所有错误中断，并打破ActiveX EXE项目中设置的未处理错误，并且您不会因为使用两个单独的进程而在类模块中断。
我喜欢亲自在Class模块中放置休息，因为它可以让我以最高的精度深入到错误的站点。这是在我开始做错误处理程序之前;在这一点上，我通常反弹所有三个，取决于我正在试图稳定。
最后，我不建议EVER使用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屋！
