In addition to logging errors, it's useful to come up with a standard way to handle errors. A centralized error handler is an ever-changing animal. As you come across new errors, you'll want to handle them consistently.
In the meantime, you'll also want to handle the majority of errors without having to create custom error handlers for each one. A centralized error handler is just the ticket. With a centralized error handler, you can have Access handle various errors the same way in all your routines, just by programming for them in one location. This section shows you how to get started.
Note
Programming your routines is just the start of what it takes to come up with a good, robust, centralized error handler. You need to customize this handler for your individual applications. The routines will help you, as the developer, get on the right track for developing your own handler that's right for your applications.
To start, it's a good idea to look at the declarations section of the modErrorHandling module, where the error-handling routines reside. The following statements are pertinent:
'-- Constants for how to handle the error. Public Const apTryAgain = 1 Public Const apExitApplication = 2 Public Const apExitRoutine = 3 Public Const apResumeNext = 4 Public Const apMultiUser = 5
These constants correspond to values assigned to possible errors. Table 7.3 shows the five constants and describes their purposes.
These errors are stored in the table tblErrorInfo, whose structure you can see in Figure 7.10. You can see some of the errors stored in tblErrorInfo in Figure 7.11, including the HowToHandle field.
In the code for ap_ErrorCheckLocal (refer to Listing 7.15), you saw a sample of how to call the centralized error handler, ap_ErrorHandler. The code in Listing 7.16 performs the actual call to the code that examines the error.
Error_ap_ErrorCheckLocal: '-- Store Error information into variables for future use. apCurrErrNo = Err.Number apCurrErrMsg = Err.Description ap_ErrorLog apModuleError, apRoutineError, apCurrErrNo, apCurrErrMsg Select Case ap_ErrorHandler(apCurrErrNo, apCurrErrMsg) Case apTryAgain Resume Case apExitRoutine Exit Sub Case apResumeNext Resume Next End Select |
As you can see from Listing 7.16, the ap_ErrorHandler() function is called with the number and description of the offending error passed as arguments. You can also see that some of the constants declared to handle the error are used to respond correctly, depending on the error.
Note
The constants apQuitApplication and apMultiUser weren't included in Listing 7.16 because both are used in ap_ErrorHandler itself.
Listing 7.17 shows the code for the ap_ErrorHandler function. But before looking at the code, note some of its features:
The error is looked up in the ErrorInfo table.
If a custom message exists in the CustomMsg field or if a message is displayed, it uses the custom message. Figure 7.12 shows such a message.
If the HowToHandle field of the error equals apExitApplication, the user is given a message saying that the error has occurred and that the application will be closed (see Figure 7.13).
If the apExitRoutine constant is needed, a message box appears to tell users that the application will be closed (refer to Figure 7.13).
If a multiuser error has occurred, special multiuser functions are called to handle the retrying of locks and such. Chapter 22 covers multiuser errors in detail and how to handle them.
Again, this centralized error-handling routine is a great starting point for you to create a custom and complete error handler of your own.
3.14.253.221