Because applications built using xfNetLink Synergy and xfServerPlus include multiple programs distributed across multiple machines, error handling design must take into account the possibility of errors occurring in any one of the programs.
Error conditions can occur on either the xfNetLink or xfServerPlus side of a remote execution session. In a distributed environment, error handling requires multiple layers of processing: the error may occur on a machine that the user does not have access to.
To help you deal with this situation, errors detected by xfServerPlus are logged to the application event log (Windows), syslog (Unix), or operator console (OpenVMS). Additional information can be logged to the xfServerPlus log. (See Using server-side logging.) This enables system administrators to track problems that have occurred even when they are not reported by a user. In addition, information about errors generated by xfServerPlus is stored in memory on the client for each active network connection ID.
There are two categories of xfServerPlus errors.
- Nonfatal errors that xfServerPlus can trap and for which it can produce a meaningful diagnostic
- Fatal errors that xfServerPlus cannot trap and which cause abnormal termination of the remote execution session
In both cases, xfServerPlus sends a message to the client. When this message is received, relevant information about the error is stored with the associated network connection ID, and a runtime error is signaled on the client (see the Synergy Runtime Errors Signaled by %RXSUBR table).
In the event of a nonfatal error, the xfServerPlus session remains available for future calls. Detailed error information can be retrieved by calling RX_GET_ERRINFO.
In the event of a fatal error, the session is aborted. Traceback information can be retrieved by calling RX_GET_HALTINFO.
You may also see xfServerPlus status codes returned to the client. See the xfServerPlus Status Codes table.
