OSF DCE Application Development Guide--Introduction and Style Guide

Chapter 7. Errors and Messaging
Applications should adopt a consistent and portable error handling style. This includes
methods for returning errors from remote procedure calls, generation of application-
specific status codes, and the generation and display of error text. This chapter
recommends a set of techniques for handling all of these issues. The chapter also makes
recommendations about error logging for applications that choose to use the logging
facilities.
7.1 Error Handling
By default, the RPC runtime generates exceptions for RPC remote and communications
errors. However, the default exception handler dumps core, which is not a very useful
client response to such errors as failure to connect with a server that is down. Although
the default error handling model attempts to treat an RPC call as a single continuous
thread, propagating server errors back to the client, it will probably be more useful for
most applications to contain the effects of server errors on the server side of the
application. In this model, the client will output an error message when, for example, the
server dumps core.
Thus, it is recommended that applications establish some explicit error handling
mechanism for RPC calls. The AES/DC recommends the use of status returns as being a
more portable way of handling errors than using exceptions. This recommendation is
also consistent with the error-handling model for the RPC API.
You can have remote calls’ communications and remote runtime errors reported through
a status parameter by specifying the [comm_status] and [fault_status] attributes for the
calls in the application’s .acf file. The IDL compiler does not require that a status
parameter be explicitly declared in the interface declaration, since it will add such a
parameter implicitly. The comm_status and fault_status parameters are not really part
of the remote interface: they are supplied by the client stub as one way of handling
remote exceptions.
However, server managers need to report application-specific errors as well. Although
such errors can be reported through function return values or a separate application error
status parameter, the most consistent method is to use a single status parameter to report
124246 Tandem Computers Incorporated 7−1