Tratamento de erros (RPC)
No RPC síncrono, um cliente faz uma chamada remota que retorna com um código de êxito ou falha. O RPC assíncrono oferece mais oportunidades para uma chamada falhar e essas falhas são tratadas de forma diferente, dependendo de onde e quando ocorrem. A tabela a seguir descreve as maneiras pelas quais uma chamada pode falhar e como ela é tratada.
Limpeza do lado do cliente
| Sintoma de falha | Limpeza |
|---|---|
| O cliente captura uma exceção quando chama o procedimento remoto. | Nenhuma chamada à API RPC é necessária. Todo o estado RPC foi limpo. |
| O cliente recebe uma notificação de chamada completa, mas quando chama RpcAsyncCompleteCall, ele recebe um código de erro. | Nenhuma chamada à API RPC é necessária. Todo o estado RPC foi limpo. |
| O cliente emite um cancelamento não anulativo ou anulativo. | O cliente deve aguardar a notificação e chamar RpcAsyncCompleteCall quando a notificação chegar. |
Na limpeza do lado do servidor, um conceito fundamental é o ponto de entrega. Durante o processamento do lado do servidor de uma chamada assíncrona, alguns processamentos geralmente são executados no thread que recebeu a chamada (também conhecido como thread do dispatcher) e, opcionalmente, o thread do dispatcher coloca estado suficiente em um bloco de memória e sinaliza outro thread (também conhecido como thread de trabalho) para continuar o processamento da chamada. O momento em que o thread do dispatcher sinaliza com êxito que o thread de trabalho é chamado de ponto de entrega.
Limpeza do Lado do Servidor
| Erro encontrado | Limpeza |
|---|---|
| Antes do ponto de entrega. | Gerar exceção. Nenhuma chamada para RpcAsyncCompleteCall é necessária. |
| Após o ponto de entrega. | Chame RpcAsyncAbortCall ou, se o erro não for fatal e os resultados ainda puderem ser retornados ao cliente, RpcAsyncCompleteCall. Se a chamada da função RpcAsyncCompleteCall falhar, o runtime do RPC liberará os parâmetros. O usuário não deve acessar esses parâmetros. O thread do dispatcher não deve executar nenhum processamento substancial que possa falhar após o ponto de entrega, pois ele não pode mais anular a chamada com segurança. Especificamente, ele não deve gerar uma exceção após o ponto de desativação da mão ou o servidor pode falhar. |
Casos especiais de tratamento de erros para pipes
Há casos especiais para tratamento de erros ao usar pipes. A lista a seguir explica a origem da falha e como lidar com o erro.
| Origem da falha | Como é tratado |
|---|---|
| O cliente chama push e a chamada falha. | Nenhuma chamada à API RPC é necessária. Todo o estado RPC foi limpo. |
| O cliente chama RpcAsyncCompleteCall antes que os pipes in sejam drenados. | A chamada falha com o código de erro de preenchimento de pipe apropriado. |
| O cliente chama pull e a chamada falha. | Nenhuma chamada à API RPC é necessária. Todo o estado RPC foi limpo. |
| O cliente ou servidor chama push ou pull na ordem errada. | O tempo de execução retorna status de erro de preenchimento de pipe. |
| O servidor chama push ou pull e a chamada falha. | Push retorna um código de falha. Nenhuma chamada para RpcAsyncCompleteCall é necessária. |
| O servidor chama RpcAsyncCompleteCall antes que os pipes sejam drenados. | A chamada de pipe retorna um erro de preenchimento de pipe status. |
| Após a expedição, uma operação de recebimento falha. | Na próxima vez que o servidor chamar pull para receber dados de pipe, um erro será retornado. |