Trapping VBA Errors

In Chapter 9, we discussed trapping errors in standard modules. This included using the On Error and If Err constructs.

You might recall that when there is no error handler in the procedure in which the error occurs, VBA passes the error to the next highest procedure in the call chain. VBA continues passing the error up the call chain until it either finds an error handler or reaches the top level, in which case it then displays the standard runtime error dialog box. If you don't handle the errors, VBA will, but you may not like the idea that it resets all your variables when it does. Certainly the users of your application won't be too impressed either.

Error trapping in class modules is exactly the same; however, you also need to consider the runtime Error Trapping setting in the IDE's Options dialog box, as shown in Figure 12-13.


Editor j Editor Format General Docking

:-orm Gnd Settings ff Show Grid

Grid Units: Points Width: Heigilt; V Align Controls to Grid

^dit and Continue f" Notify Before State Loss trror Trapping C Break on All Errors

Break In Class Module f* Break on Unhandled Errors

P Show ToolTips v Collapse P™. Hides Windows

Compile v Compile On Demand P Background Compile m



The Error Trapping settings control how Access handles runtime errors. The default setting, Break on Unhandled Errors, causes Access to display the standard Windows runtime error dialog box in the absence of any error handlers in the call chain. This is the desired behavior, because it lets your error handlers do their job.

Break on All Errors causes Access to override all your error handlers and display the runtime error dialog box whenever an error occurs in any module (including class modules). Finally, the Break in Class Module option overrides your class module error handlers, but not those in standard modules.

0 0

Post a comment