visual studio - Break in Class Module vs. Break on Unhandled Errors (VB6 Error Trapping, Options Setting in IDE)

Question

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:

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).

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.

Answer 1

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.