Assume that you have an application that reads from stock quote servers and displays graphs of the data. Since you do not expect to get server failures because it is a commercial-quality server, you are not interested in writing code to handle values returned from fault_status. If high availability and robustness is important, you may have a list of recovery plans to make sure a stock analyst can get the necessary information as quickly as possible. For example:
retry_count = 10;
do {
query_stock_quote(h, ...,&st);
switch (st) /* st parameter can be used because */
{ /* [comm_status] is in the ACF */
case rpc_s_ok:
break;
case rpc_s_comm_failure:
retry_count -= 1;
break;
case rpc_s_network_unreachable:
h = some_other_handle;
break;
case
.
.
.
default:
retry_count -= 1;
}
}
while ((st == rpc_s_ok) || (retry_count <= 0))
If this is not a critical application, you may only report that the server is currently unavailable. Depending upon the design of the application, there may be several places to put the exception handler to report the failure but continue processing. For example:
TRY
update_a_quote(...);
CATCH_ALL
display_message("Stock quote not currently available");
ENDTRY
This example assumes that update_a_quote( ) eventually calls the remote operation query_stock_quote( ) and that this call may raise an exception that is detected and reported here.
The advantage of using exceptions in this case is that all of the work done in update_a_quote( ) has the same error recovery and it does not need to be repeated at every call to a remote operation. Another advantage is that, if one of the remote operations does have a recovery for one exception, it can handle that one exception and allow the rest to propagate to the more general handler in an outer layer of the code.