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 all errors. In this way a client need not concern itself with two or three separate error parameters, and can use a consistent error handling scheme for both API and application RPC errors. In order to return application-specific errors, such a status parameter must be part of the IDL specification of the interface. The recommended method is therefore to declare a status parameter as part of the application's \&.idl file declarations, and then add the [com_status] and [fault_status] attributes to the parameter by declarations in the .acf file.
Of course, if application and DCE runtime errors are to share the same status parameter, they must use disjoint error number spaces. The DCE messaging facilities provide a means to do this.