Raising an Error to Pass Back to the Client

This method has a more "in-your-face" attitude toward the client. It generates a hard error condition in the client and forces the client to do its own error handling to deal with the server's error.

As you can see in Listing 12.16, the method in the server does not have to be a function, because we're not using its return code to signal a success-or-failure status. The method still uses an error handler as it did in the previous technique, but now instead of setting a return value, it uses Err.Raise to cause another error to happen in the error handler.

You append the Visual Basic predefined constant vbObjectError to the error code you are raising. This tells the system to pass the error through to the client. When the client receives the error, the value of vbObjectError will be stripped off the error code it sees, and the client will see only the error code's original value.

Because an error now occurs in the client, the client must have its own error-handling routine in place.

LISTING 12.16
GENERATING AN ERROR IN THE CLIENT

[Method in the server class]

Public Sub MyMethod2 ()
   On Error GoTo MyMethod2_Error
   .
   . 'do stuff that could possibly cause an error
   .
Exit Sub
MyMethod2_Error:
   'client will see Err.Number as 1000
   Err.Raise 1000 + vbObjectErrorlient
End Sub

[Code in the client application]

   On Error GoTo MyCall_Error
   MyServer.MyMethod2
   Exit Sub
MyCall_Error:
   ' do something to handle the error

Note that Visual Basic's default error-handling strategy at design time is to always break in the class of the server application. To be able to test code that uses the strategy discussed here, you must set the general option known as Error Trapping to Break on Unhandled Errors.