Common Error-Handling Routines

Sometimes while you are creating an application with error-handling routines in procedures, you may find yourself writing the same code over and over again. All your error-handling routines may be anticipating the same error numbers. Instead of duplicating the same error-handling code in many procedures, you can create a common error-handling function and call it from the individual errorhandling routines within your other procedures.

Assume, for example, that you are developing an application that does extensive file processing. You find that many of your procedures check for errors 53 (File Not Found), 58 (File Already Exists), and 61 (Disk Full). Without a common error-handling routine, you might find yourself coding the following in every procedure that references files:

fErrorHandler:

   Dim msg As String

   Select Case Err.Number
      Case 53 ' file not found
         msg = "File not found. Do you want to try again?"
         If MsgBox(msg, vbYesNo) = vbYes Then
            Resume
         Else
            Exit Function
         End If
      Case 58 ' file already exists
         msg = "The file already exists. Do you wish to overlay?"
         If MsgBox(msg, vbYesNo) = vbYes Then
            Resume Next
         Else
            Exit Function
         End If
      Case 61 ' disk full
         MsgBox "The disk you specified is full. The operation cannot continue."
         End
   End Select

Your error handlers can be even longer, trapping additional errors that your users might encounter.

Instead of repeating the same code many times in different procedures, you should move your error-handling code to a common errorhandling function. You may find yourself not only using the common function many times within a project, but also find yourself including the common error handling in many projects you write. For this reason it is best to put your common error-handling function in a separate standard module so it can be easily ported to other projects.

When you create a common error-handling function, consider the following:

A common error-handling routine needs to know what error occurred. The easiest way to pass this information is by passing the Err object to the function.
You need to know the results of the error handling. Will execution continue? Should the line of code that caused the exception be bypassed or run again? This information can be passed back as the return value or as an argument of the function.
The error-handling function or module may be used in other projects. Try not to reference forms or procedures specific to one project. This will prevent rewrites later.
Code the function to handle as many trappable errors as you can. The more types of errors you trap for the more specific and user-friendly your error handling can be. Even if you do not code for all the trappable errors, you can add to the function at a later time.
Include handling of any errors for which you do not have specific error handling. For example, your error handler may trap for errors 53, 58, and 61. Include some code to handle any other errors. Unexpected errors always occur in applications. In addition future releases of Visual Basic may include more trappable errors than the current release.

When you create an error-handling function, you must decide how to tell a calling procedure what should be done after the error handling has completed. Do you want the code to retry (Resume), bypass the code (Resume Next), or shut down the application?

One way to do this is to pass back the information through the return code of the function by using constants:

Public Const iRESUME = 1
Public Const iRESUME_NEXT = 2
Public Const iEXIT_PROCEDURE = 3
Public Const iEXIT_PROGRAM = 4

Remember to include the constant definitions in the BAS module that contains the error-handling function.

The error code that you previously had in many procedures throughout your application can now be combined into one error-handling function:

Public Function fErrorHandler(objError As Object) As Integer

   Dim msg As String

   Select Case objError.Number

      Case 53 ' file not found
         msg = "File not found. Do you want to try again?"
         If MsgBox(msg, vbYesNo) = vbYes Then
            fErrorHandler = iRESUME
         Else
            fErrorHandler = iEXIT_PROCEDURE
         End If

      Case 58 ' file already exists
         msg = "The file already exists. Do you wish to overlay?"
         If MsgBox(msg, vbYesNo) = vbYes Then
            fErrorHandler = iRESUME_NEXT
         Else
            fErrorHandler = iEXIT_PROCEDURE
         End If

      Case 61 ' disk full
         MsgBox "The disk you specified is full. The operation cannot continue."
            fErrorHandler = iEXIT_PROGRAM
      Case Else ' covers all other errors
      msg = objError.Number & "=" & objError.Description & _
      vbCrLf & "Source = " & objError.Source
      MsgBox msg
      fErrorHandler = iEXIT_PROGRAM

   End Select

End Function

Now that your error handling has been centralized in a common function, the error handling in individual procedures can be simplified to something that looks like this:

sub1_error:

   Select Case fErrorHandler(Err)
      Case iRESUME
         Resume
      Case iRESUME_NEXT
         Resume Next
      Case iEXIT_PROCEDURE
         Exit Sub
      Case iEXIT_PROGRAM
         End
      End Select

For most of your procedures, the preceding code will be sufficient for handling errors. The common error function will be called, and the way of handling any given error will be returned. There are always times, however, where you will customize the error handling in different sub-routines and functions to handle unique situations. For these cases it is best not to alter a common error-handling function.