Alison Balteramp;#039;s Mastering Microsoft Office Access 1002003 [Electronic resources] نسخه متنی

Building a Custom Error Handler Class

Implementing error handling within an application can be very tedious, especially if you attempt to place specific error-handling logic in each routine you write. Although implementing a generic error handler does not mandate the use of a class module, using a class module greatly facilitates the process of implementing error handling within your applications. Listing 16.29 illustrates this point.

Listing 16.29 An Example of an Access Subroutine

When an error occurs, your code instantiates the ErrorHandler class. The Initialize event of the class executes, as shown in Listing 16.30.

Listing 16.30 The Initialize Event of the ErrorHandler Class

The Initialize event of the class sets the module-level variables mstrUserName and mdatDateTime equal to the CurrentUser and the current date and time, respectively. The Username and DateTime properties of the class use these variables.

The code then executes the ErrorProcess method of the ErrorHandler class, which logs the error and then takes appropriate action in response to the error. It appears in Listing 16.31.

Listing 16.31 The ErrorProcess Method of the ErrorHandler Class

The routine first sets the ModuleName, Routine, ErrorMessage, and ErrorNumber variables within the class to the values of the parameters passed to the ErrorProcess method. The Property Get routines for the ModuleName, Routine, ErrorMessage, and ErrorNumber properties, which are responsible for manipulating error information, appear in Listing 16.32. Because we only want the properties to be set via the ErrorProcess method, no Property Let routines exist.

Listing 16.32 The Property Get Routines of the Class

As you can see, the Property Get routines retrieve the values from their associated module-level variables.

Next, the function calls a routine that logs the error that occurred. This LogError routine is shown in Listing 16.33. The LogError routine uses ADO code to add a record to the tblErrorLog table. The record contains all the information about the error that occurred. Notice that the error information is retrieved from the module-level variables populated by the ErrorHandler class's ErrorProcess method.

Listing 16.33 The LogError Subroutine

[View full width]

Sub LogError()
'Declare a Connection object
Dim cnn As ADODB.Connection
Dim strSQL As String
'Point the Connection object at the connection
'associated with the current project
Set cnn = CurrentProject.Connection
'Build a SQL statement that inserts error information
'into the tblErrorLog table
strSQL = "INSERT INTO tblErrorLog ( ErrorDate, ErrorTime, UserName, ErrorNum,
ErrorString, ModuleName, RoutineName) "
strSQL = strSQL & "Select #" & Me.DateTime & "#, #" _
& Me.DateTime & "#, '" _
& Me.UserName & "', " _
& Me.ErrorNumber & ", '" _
& Me.ErrorMessage & "', '" _
& Me.ModuleName & "', '" _
& Me.Routine & "'"
'Execute the SQL statement
cnn.Execute strSQL, , adExecuteNoRecords
End Sub

After the error is logged, the number of the error that occurred is looked up in the tblErrors table. If it is not found in the tblErrors table, a form is displayed, containing all the critical information about the error that occurred. The value contained in the constant ERR_QUIT is returned from the ErrorHandler function. If the error number is found in the tblErrors table, the value contained in the Response field is evaluated. If it is the value contained in the constant ERR_QUIT, the frmError form is displayed, and the value in the constant ERR_QUIT is returned from the ErrorHandler method. If the Response field contains the value of the ERR_RETRY constant, that value is returned from the method, without the frmError form being displayed. If the Response field contains the value associated with the ERR_EXIT constant, the frmError form is displayed, and the ERR_EXIT value is returned from the ErrorHandler method. Finally, if the value in the Response field is the value associated with the ERR_CONTINUE constant, no error information is displayed, and the ERR_CONTINUE value is returned from the ErrorHandler method.

All the code contained in the ErrorHandler class is similar to that contained in the basErrorHandler module. The code has been modified so that it is implemented using properties and methods of a Class object.

The other code that is changed to use classes is the code behind the error form. Listing 16.34 shows the load event of the error form, modified to call methods of the appropriate classes.

Listing 16.34 The Form_Load Event of the Error Form

Notice that instead of calling the GetSysInfo function and the GetErrorInfo function, the load event executes the GetSysInfo method of the SystemInformation object and the GetErrorInfo method of the ErrorHandler object.

The GetSystemInfo function and associated declarations were moved to a SystemInformation class. No other changes were made to the code.

The GetErrorInfo function was moved to the ErrorHandler class and modified to retrieve properties of the class, as shown in Listing 16.35.

Listing 16.35 The GetErrorInfo Method of the ErrorHandler Class Retrieving Properties of the Class

Notice that instead of using a type structure, the code references its own properties. The Private variables associated with these properties were set by the ErrorProcess method of the class.