Microsoft Access 2010 Bible

(Rick Simeone) #1

Chapter 23: Handling Errors and Exceptions ..............................................................................


821


Runtime errors
If you get past the syntax checking using the VBA editor and your code compiles, you may still
encounter errors. Those errors, which occur as the user works with an application, are generally
referred to as runtime errors. Runtime errors occur for a multitude of reasons, such as unexpected
data values (zero values or numbers that are too large to fit in the data type) or expected external
files not being present. When a runtime error occurs, it results in one of following situations:

l (^) A fatal error occurs, which causes the application to crash.
l An untrapped error occurs, and the default Access error dialog box appears.
l (^) The error is handled by the application and your code takes care of the problem.
l An unanticipated application error occurs, which may or may not cause problems with
your Access application.
I examine each of these situations in the following sections.
When fatal errors occur
A fatal error is a non-recoverable error and crashes the application. Fatal errors are generally the
result of an operation outside the Access environment, and there is no way for Access to handle it.
In most cases, your code won’t be able to trap and respond to fatal errors. An example of this type
of error is calling a poorly written Windows API function. As you’ll see in Chapter 27, Windows
API functions are extremely fussy about the type and number of parameters passed to them.
Because Windows API functions execute outside of Access, there is no way for VBA code to trap an
API error. In extreme cases, your users encounter the dreaded blue screen of death (BSOD), often
seen when a computer is infected by a virus.
Tip
Because you can’t do much about these fatal errors other than fix them, you should concentrate on the types
of errors you can control.
When Access reports the error
Runtime errors often give no direct indication of a problem, such as a pop-up message on a screen.
More likely, a runtime error is detected after the fact, when something with the data is discovered
to be wrong. For instance, a report may contain blank text boxes when the user expects to see
names and other data. This situation could even occur a long time after the data-entry error has
occurred, and the error may occur many times before its discovery.
On rare occasions, runtime errors are traceable to a hardware failure such as a full disk or network
problems, leading to the frequent “It’s the *&#^ computer’s fault!” complaint. Modern desktop
computers are much more reliable than they were a few years ago, making this situation a rare
occurrence. Many hardware failures, such as a hard-disk crash, are easily recognized by the user.

Free download pdf