This "soft" method of error handling will not generate an error condition
in the client. It will let the controlling application decide whether it is worth
checking for an error after calling a method of your server. If the controlling
application does check your server method's return value, it can determine whether
an error occurred and decide what to do next.
To implement this technique, you should write your server methods as functions with an Integer
return type. The return type will be, say, zero or some other encouraging-sounding number if no
error happens in the function. You need to write and enable an error-trapping routine in the function
that will cause the function to return a negative integer or some other equally dire value when
an error does occur. The code in Listing 12.15 illustrates both client- and serverside code to
implement this solution.
LISTING 12.15
RETURN AN ERROR STATUS CODE TO THE CLIENT
[Method in the server class]
Public Function MyMethod () as Integer
'Initialize return value to OK
MyMethod = 0
On Error GoTo MyMethod_Error
.
. 'do stuff that could possibly cause an error
.
Exit Function
MyMethod_Error:
'return error code
MyMethod = Err.Number
Resume Next
End Function
[Code in the client application]
Dim iResult as Integer
iResult = MyServer.MyMethod()
'Check method's result code for an
error
If iResult <> 0 then
' do something to handle
the error
End If
'Or - Following line ignores the method's
result code
MyServer.MyMethod
The client can then check the return value of the server's method to see whether all has
gone well. If it gets an error code back from the method, it can then decide what to do.
NOTE - Programmer-Defined Error Codes : With this type of error
handler, you might consider implementing your own system of error codes. You must use integer
values higher than 512, because lower values can conflict with existing ActiveX error codes.
Raising an Error to Pass Back to the Client
