Error Trapping: Break In or Break On Options

[Previous] [Next]

Now I want to turn to the different error trapping options you can use. The Visual Basic IDE can run in three modes: design mode, for when you're coding; run mode, for when your application is running under the debugger; and break mode, for when your application is stopped under the debugger.

When your application hits a location breakpoint, the IDE automatically drops into break mode. When your application generates an error, however, the IDE might or might not drop into break mode, depending on which of the following three options is set:

• Break On All Errors
• Break On Unhandled Errors
• Break In Class Module

When I first started programming in Visual Basic, I couldn't get a class that had a run-time error I was handling to drop into break mode. After much gnashing of teeth, I finally found the secret menu that allowed me to set these error trapping options.

You can set the default error trapping option on the General tab of the Options dialog box. The Visual Basic default is Break In Class Module. You can also change the error trapping option on the fly by right-clicking in a source window, selecting the Toggle pop-up menu, and choosing a different error trapping option.

Break On All Errors

Just as the name Break On All Errors implies, whenever the Visual Basic debugger encounters an error, the debugger will stop with the run-time error dialog box shown in Figure 7-1. Any error will cause a break, even if you have an error handler for the error in your code. Generally, this error trapping option isn't that useful. I use this option only if I need to see where a particular error is raised when it occurs in a function without any error handlers.

Figure 7-1 The Visual Basic run-time error dialog box

Essentially, when you set the Break On All Errors error trapping, you're turning off all error handlers built into your code. When your application breaks on the error, you can continue running by dragging the currently executing line arrow down to the next executable line after the location that raised the error or by using the Set Next Statement option on the right-click menu. The only problem with changing the executing line is that Visual Basic won't raise the actual error for you to handle.

Break On Unhandled Errors

As its name suggests, Break On Unhandled Errors will force the debugger into break mode if an error is raised and you don't have an error handler for the raised error. Break On Unhandled Errors works great for almost all situations, and I've set this as my default error trapping option.

Unfortunately, if you're debugging Component Object Model (COM) server systems, both in-process and out-of-process, you won't break on errors from your class modules. COM does the right thing and packages your raised errors and transmits them back to the client as normal COM errors. If you want to break in COM servers, you need to set the error trapping option to Break In Class Modules.

Break In Class Modules

Break In Class Modules is for debugging COM servers. When you select this error trapping option, you're telling the debugger that you want to treat all errors in class modules as if there are no error handlers. Although Break In Class Modules allows you to get to errors in COM servers, you're still stuck with the fact that your error handlers are ignored.

A Final Plea for Decent Error Trapping

As you can tell from this discussion, error trapping in the Visual Basic debugger leaves quite a bit to be desired. If you want to break on errors, you can do so, but at the expense of being able to step through your error handlers. The only real workaround is to set breakpoints on all the error handlers you're interested in stepping through and to set the error trapping option to Break On Unhandled Errors. What we really need is a way to break on errors but still process them through our normal error handling after breaking.

I hope that the Visual Basic development team will take pity on those of us who want to debug our applications completely and allow us to trap errors yet still let us test the error handlers from the point at which an error is raised. The artificial limits imposed on error trapping in the Visual Basic debugger make it difficult to debug applications.

Because the error trapping problems are related directly to the On Error GoTo constructs in Visual Basic, you need to pay special attention to how you use error handlers in your code. I was going to write a section in this chapter about proper error handling, but Peet Morris wrote what I consider the definitive text in Chapter 1, "On Error GoTo Hell," in the book Advanced Microsoft Visual Basic 6.0 by The Mandelbrot Set (2nd ed., Microsoft Press, 1998). If you're even thinking about doing Visual Basic development, Peet's chapter is a mandatory read.