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
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
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
'client will see Err.Number
Err.Raise 1000 + vbObjectErrorlient
[Code in the client application]
On Error GoTo MyCall_Error
' do something to handle
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.