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.