Gestion des erreurs (RPC)

Dans rpc synchrone, un client effectue un appel distant qui retourne avec un code de réussite ou d’échec. Le RPC asynchrone offre davantage de possibilités d’échec d’un appel, et ces échecs sont gérés différemment, selon l’endroit et le moment où ils se produisent. Le tableau suivant décrit les façons dont un appel peut échouer et comment il est géré.

Nettoyage côté client

Symptôme d’échec	Nettoyage
Le client intercepte une exception lorsqu’il appelle la procédure distante.	Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Le client reçoit une notification d’appel terminé, mais quand il appelle RpcAsyncCompleteCall, il reçoit un code d’erreur.	Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Le client émet une annulation non abandonnée ou non abandonnée.	Le client doit attendre la notification et appeler RpcAsyncCompleteCall lorsque la notification arrive.

 

Dans le nettoyage côté serveur, un concept clé est le point de transfert. Pendant le traitement côté serveur d’un appel asynchrone, un traitement est généralement effectué sur le thread qui a reçu l’appel (également appelé thread de répartiteur), puis, éventuellement, le thread de répartiteur place suffisamment d’état dans un bloc de mémoire et signale à un autre thread (également appelé thread de travail) la poursuite du traitement de l’appel. Moment auquel le thread de répartiteur signale correctement que le thread de travail est appelé point de transfert.

Nettoyage côté serveur

Erreur rencontrée	Nettoyage
Avant le point de transfert.	Lever l’exception. Aucun appel à RpcAsyncCompleteCall n’est nécessaire.
Après le point de transfert.	Appelez RpcAsyncAbortCall ou, si l’erreur n’est pas irrécupérable et que les résultats peuvent toujours être retournés au client, RpcAsyncCompleteCall. Si l’appel de fonction RpcAsyncCompleteCall échoue, le runtime RPC libère les paramètres. L’utilisateur ne doit pas accéder à ces paramètres. Le thread de répartiteur ne doit pas effectuer de traitement important susceptible d’échouer après le point de transfert, car il ne peut plus abandonner l’appel en toute sécurité. Plus précisément, il ne doit pas lever d’exception après le point de transfert, sinon le serveur peut se bloquer.

 

Cas spéciaux de gestion des erreurs pour les canaux

Il existe des cas spéciaux pour la gestion des erreurs lors de l’utilisation de canaux. La liste suivante explique la source de l’échec et comment gérer l’erreur.

Source de l’échec	Gestion
Le client appelle push et l’appel échoue.	Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Le client appelle RpcAsyncCompleteCall avant que les canaux in soient vidés.	L’appel échoue avec le code d’erreur de remplissage de canal approprié.
Le client appelle pull et l’appel échoue.	Aucun appel d’API RPC n’est nécessaire. Tout l’état RPC a été nettoyé.
Le client ou le serveur appelle par push ou par extraction dans le mauvais ordre.	L’exécution retourne une erreur de remplissage de canal status.
Le serveur appelle push ou pull et l’appel échoue.	L’envoi (push) retourne un code d’échec. Aucun appel à RpcAsyncCompleteCall n’est nécessaire.
Le serveur appelle RpcAsyncCompleteCall avant que les canaux aient été vidés.	L’appel de canal retourne une erreur de remplissage de canal status.
Après la distribution, une opération de réception échoue.	La prochaine fois que le serveur appelle pull pour recevoir des données de canal, une erreur est retournée.