CHAPTER  8

Handling Run-Time Errors

Part of application development is to anticipate and plan for the errors users may encounter. While your application is running, external events that you can't prevent or may not anticipate are likely to occur. For example, files may be mistakenly deleted, disk drives can run out of space, and network drives sometimes disconnect unexpectedly. Such eventualities can cause run-time errors in your code, that is, errors that Microsoft Access can detect only when your application is running. To handle these errors, you need to add error-handling code to your procedures.

Errors and Error Handling

In the world of programming, an error often isn't the same as a mistake. An error may be the result of an event or an operation that doesn't work out as expected, or the result of an attempt to carry out an impossible or invalid maneuver.

Often, you can anticipate the errors that users will encounter when they work with your application. You can shield users from these errors by including error-handling code, also known as error trapping, in your application. You don't have to use error handling in every procedure that you write, but it's a good idea to include it whenever your application interacts with something external, like the user's machine, a network, or a remote database. You should also use error handling when your application opens, updates, deletes, or adds a database record.

Error-handling code typically traps a run-time error by interrupting the default Microsoft Access response to the error and instead running code that you specify. Your application can correct the error, or give the user an opportunity to correct the error.

Run-time errors occur when the application is actually running; other types of errors can occur under different circumstances. For example, a syntax error can occur when you enter code in the Module window, and a compile error can occur when you compile code. In Microsoft Access, however, you can trap only run-time errors.

Depending on where it occurs, you can handle a run-time error in one of two ways.

If your application uses Visual Basic code, you usually have to use both types of error handling.

Both types of error handling require that you identify each error you want to handle by its error code. You usually declare a constant to represent the numeric error code, and then use the constant to refer to the error. You can create an Errors table in Microsoft Access that contains the error codes and strings used or reserved by Visual Basic. Search the Help index for "trapping errors," and then click Determine the Error Codes Reserved by Visual Basic. You can copy and paste the CreateErrorsTable procedure from this Help topic into a module.

See Also   For information on using Visual Basic to create tables, see Chapter 5, "Working with Objects and Collections," and Chapter 9, "Working with Records and Fields."

After you create the Errors table, you can find the error code for an error by looking up its corresponding error message. To do so, open the Errors table, select the Error String column, click Find on the Edit menu, type the error message in the Find What box, and then click Find First. You can also base a query or report on the table, or sort the Error String column.

See Also   For a list of data access errors, search the Help index for "errors, trapping," and then click Trappable Data Access Errors.

The Err Object, the Errors Collection, and the Error Function

Microsoft Access provides the Err object and the Errors collection to help you retrieve information about run-time errors in your applications, and regenerate errors when necessary.

Microsoft Access uses the Err object to store information about the most recent run-time error that has occurred. When a run-time error occurs, the properties of the Err object are filled with information that uniquely identifies the error's number, description, and source. Depending on the type of error that is generated, you may also be able to obtain other information about the error.

You can also use the Err object to regenerate errors that have occurred in your application.

See Also   For information on regenerating errors with the Err object, see "The Raise Method" later in this chapter.

The Errors collection is contained by the DBEngine object. It contains one Error object for each error that is generated by a single operation involving Data Access Objects (DAO). If multiple errors occur during a single operation, then the collection contains more than one Error object. When another operation generates an error or errors, the existing collection is cleared and refreshed with a new set of Error objects. Unlike other collections, the Errors collection doesn't append objects to existing objects as subsequent operations occur.

In addition to the Error object and the Errors collection, there is also an Error function. The Error function returns the error description that corresponds to a given error number. The Error function and the Description property of the Err object return the same value.

See Also   For more information about the Err object, the Error object, the Errors collection, or the Error function, search the Help index for the name of the object, collection, or function.

© 1996 Microsoft Corporation. All rights reserved.