CREATING A CENTRALIZED ERROR-HANDLING ROUTINE

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.

Table 7.3. Error Values
Error Number Meaning
1 Retry; performs a Resume immediately
2 Terminate App; immediately closes the application
3 Terminate Function; like Terminate App but simply exits the current function that was executing
4 Resume Next; continues with the next line of code
5 Multiuser; treats the error as a multiuser error, calling a special function named ap_ErrorTryMUAgain(), which displays a message while it retries the command

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.

Figure 7.10. This structure for the tblErrorInfo table allows for custom error messages.


Figure 7.11. You can let Access know how to handle errors automatically.


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.

Listing 7.16. VideoApp.mdb: Calling the Centralized Error Handler
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.

    Figure 7.12. Display any custom message you want for an error.

  • 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).

    Figure 7.13. You can let users know that the application will be closed.

  • 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.

Listing 7.17. VideoApp.mdb: The Centralized Error Routine Itself
Function ap_ErrorHandler(lngCurrErrNo, strOrigErrorMsg) As Integer

    Dim dbLocal As Database
    Dim qdfCurrError As QueryDef
    Dim dynCurrError As Recordset
    Dim intHowTohandle As Integer
    Dim strErrorMsg As String

    On Error GoTo Error_ap_ErrorHandler

    lngCurrErrNo = CLng(lngCurrErrNo)
    Set dbLocal = CurrentDb()

    '-- Get the entry in ErrorInfo for the current error occurring.
    Set qdfCurrError = dbLocal.QueryDefs("qryCurrError")
    qdfCurrError.Parameters("CurrError") = lngCurrErrNo
    Set dynCurrError = qdfCurrError.OpenRecordset()

    If dynCurrError.RecordCount > 0 Then

        '-- If a custom message has been created, use it.
        strErrorMsg = IIf(IsNull(dynCurrError!CustomMsg), _
           "The following error has occurred: " & strOrigErrorMsg, _
             dynCurrError!CustomMsg)

        '-- Store how to handle the error to a variable
        intHowTohandle = dynCurrError!HowToHandle

        '-- Check to see how this error is to be handled
        Select Case intHowTohandle

            Case apExitApplication

              '-- if quit the application, give a message saying so,
              '-- then quit.
              strErrorMsg = strErrorMsg & vbCrLf & vbCrLf & _
                  "The application will be closed"

              Beep
              MsgBox strErrorMsg, vbCritical, "Critical Error"
              Application.Quit

            Case apExitRoutine

              '-- If exiting the routine, give a message saying
              '-- the task has been stopped.
              strErrorMsg = strErrorMsg & vbCrLf & vbCrLf & _
                  "Some tasks may have not been performed"
              Beep
              MsgBox strErrorMsg, vbCritical, "Task Error"

            Case apMultiUser

              '-- For multi-user errors try a couple of times,
              '   then check with user.
              If ap_ErrorTryMUAgain(strOrigErrorMsg) Then
                  '-- If user wants, try again
                  intHowTohandle = apTryAgain
              Else
                  '-- If struck out, exit the routne
                  intHowTohandle = apExitRoutine
              End If

            Case Else

              '-- If exiting the routine, give a message saying
              '-- the task has been stopped.
              strErrorMsg = strErrorMsg & vbCrLf & vbCrLf & _
                  "Some tasks may have not been performed." & _
                  " Note this error has not been categorized."
              Beep
              MsgBox strErrorMsg, vbCritical, "Task Error"
              '-- If struck out, exit the routine
              intHowTohandle = apExitRoutine
        End Select

    Else

        Beep
        MsgBox "Error not known"

        '-- if unknown error, then exit the function
        intHowTohandle = apExitRoutine

    End If

Exit_ap_ErrorHandler:

    '-- Pass back how to handle the error
    ap_ErrorHandler = intHowTohandle
    Exit Function

Error_ap_ErrorHandler:

    '-- Create a simple error handler for this routine
    MsgBox "An Error occurred in the error handler", vbCritical, _
         "Error Handler Problem"

    intHowTohandle = apExitRoutine

    Resume Exit_ap_ErrorHandler

End Function

Again, this centralized error-handling routine is a great starting point for you to create a custom and complete error handler of your own.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.14.253.221