A distributed computer system has multiple points of failure, making it complex to debug. Because the user interface is on the client machine, errors in your server application cannot be handled by writing a message to the screen of the machine on which your Synergy routines are executed. (This could be the screen of a server that no one is looking at.) Nor can you rely on information from tracebacks. You must trap and handle errors in some other manner. The best way to do this is to trap for all possible errors on the server side and have your routines return status information (success, failure, or an error number) via the return result or the argument list. This allows processing to continue even though an error occurred. (If you are modifying existing routines for use with xfServerPlus, you may want to convert them to ^VAL functions, which enable you to return a status value without altering your argument list.)
On the client side, your code should check for errors—both xfServerPlus errors and errors from the client code.
To help you deal with the complexities of troubleshooting in a distributed environment, errors detected by xfServerPlus are always logged to the application event log (Windows), syslog (Unix), or operator console (OpenVMS). Errors may also be logged to the xfServerPlus log if you have server-side logging turned on. (See Using server-side logging.) This enables the system administrator to track problems that have occurred even if they are not reported by a user. You can also activate client-side logging. For information on handling errors for the individual xfNetLink clients, refer to the following:
- Synergy, see Handling xfNetLink Synergy errors
- Java, see Handling xfNetLink Java exceptions
- .NET, see Handling xfNetLink .NET exceptions
