Some conditions are better for using the comm_status or fault_status attribute on an operation, rather than the default approach of handling exceptions.
The comm_status attribute is useful only if the call to the operation has a specific recovery action to perform for one or more communications failures; for example, rpc_s_comm_failure or rpc_s_no_more_bindings. The comm_status attribute is recommended only when the application knows that it is calling a remote operation. If you expect communications to fail often because the server does not have enough resources to execute the call, you can use this attribute to allow the call to be retried several times. If you are using an implicit or explicit binding, you can use the comm_status attribute if you want to try another server because the operation cannot be performed on the one you are currently using. You can also use an exception handler for each of the two previous instances.
In general, the advantage of using comm_status if the recovery is local to the routine is that the overhead is less. The disadvantage of using comm_status is that it results in two different operation signatures. Distributed calls contain the comm_status attribute, however; local calls do not. Also, if all of the recovery cannot be done locally (where the call is made), there must be a way to pass the status to outer layers of code to process it.
The fault_status attribute is useful only if the call to the operation has a specific recovery action to perform for one or more server faults; for example, rpc_s_invalid_tag, rpc_s_fault_pipe_comm_error, rpc_s_fault_int_overflow, or rpc_s_fault_remote_no_memory. Use fault_status only when the application calls a remote operation and wants different behavior than if it calls the same operation locally. If you are requesting an operation on a large data set, you can use this attribute to trap rpc_s_fault_remote_no_memory and retry the operation to a different server, or you may break your data set into two smaller sections. You can also handle the previous case with exception handlers. The advantage of using fault_status if the recovery is local is that the overhead is less. The disadvantage of fault_status is that the operation is different between the local and distributed case. Also, if all of the recovery cannot be done locally, there must be a way to pass the status to outer layers of code to process it.