Obsługa błędów (RPC)
W przypadku synchronicznego wywołania RPC klient wykonuje zdalne wywołanie, które zwraca kod powodzenia lub niepowodzenia. Asynchroniczne wywołanie wywołania nie powiodło się, a te błędy są obsługiwane inaczej w zależności od tego, gdzie i kiedy wystąpią. W poniższej tabeli opisano sposoby, w jaki wywołanie może zakończyć się niepowodzeniem i jak jest obsługiwane.
Oczyszczanie po stronie klienta
| Objaw niepowodzenia | Oczyszczania |
|---|---|
| Klient przechwytuje wyjątek, gdy wywołuje procedurę zdalną. | Nie są wymagane żadne wywołania interfejsu API RPC. Wszystkie stany RPC zostały wyczyszczone. |
| Klient odbiera pełne powiadomienie o wywołaniu, ale gdy wywołuje RpcAsyncCompleteCall, otrzymuje kod błędu. | Nie są wymagane żadne wywołania interfejsu API RPC. Wszystkie stany RPC zostały wyczyszczone. |
| Problemy z klientem, które nie zostały przerwane lub przerwane. | Klient musi czekać na powiadomienie i wywołać RpcAsyncCompleteCall po nadejściu powiadomienia. |
W przypadku oczyszczania po stronie serwera kluczową koncepcją jest punkt przekazywania. Podczas przetwarzania po stronie serwera wywołania asynchronicznego niektóre operacje przetwarzania są zwykle wykonywane w wątku, który odebrał wywołanie (znane również jako wątku dyspozytora), a następnie, opcjonalnie, wątek dyspozytora umieszcza wystarczający stan w bloku pamięci i sygnalizuje inny wątek (znany również jako wątku roboczego) w celu kontynuowania przetwarzania wywołania. Moment, w którym wątek dyspozytora pomyślnie sygnalizuje, że wątek procesu roboczego jest nazywany punktem przekazywania .
Oczyszczanie po stronie serwera
| Napotkano błąd | Oczyszczania |
|---|---|
| Przed przekazaniem punktu. | Zgłaszanie wyjątku. Nie jest konieczne wywołanie RpcAsyncCompleteCall. |
| Po przekazaniu punktu. | Wywołaj RpcAsyncAbortCall lub, jeśli błąd nie jest krytyczny i wyniki nadal mogą zostać zwrócone do klienta, RpcAsyncCompleteCall. Jeśli wywołanie funkcji RpcAsyncCompleteCall zakończy się niepowodzeniem, środowisko uruchomieniowe RPC zwalnia parametry. Użytkownik nie może uzyskać dostępu do tych parametrów. Wątek dyspozytora nie może wykonać żadnego istotnego przetwarzania, które może zakończyć się niepowodzeniem po zakończeniu przekazywania, ponieważ nie może już bezpiecznie przerwać wywołania. W szczególności nie może zgłosić wyjątku po punkcie odręczny lub serwer może ulec awarii. |
Specjalne przypadki obsługi błędów dla potoków
Istnieją specjalne przypadki obsługi błędów podczas korzystania z potoków. Na poniższej liście wyjaśniono źródło błędu oraz sposób obsługi błędu.
| Źródło awarii | Jak obsłużone |
|---|---|
| Klient wywołuje wypychanie, a wywołanie kończy się niepowodzeniem. | Nie są wymagane żadne wywołania interfejsu API RPC. Wszystkie stany RPC zostały wyczyszczone. |
| Wywołania klienta RpcAsyncCompleteCall przed opróżnienie potoków w potokach. | Wywołanie kończy się niepowodzeniem z odpowiednim kodem błędu wypełniania potoku. |
| Wywołania klienta ściągają, a wywołanie kończy się niepowodzeniem. | Nie są wymagane żadne wywołania interfejsu API RPC. Wszystkie stany RPC zostały wyczyszczone. |
| Klient lub serwer wywołuje wypychanie lub ściąganie nieprawidłowej kolejności. | Czas wykonywania zwraca stan błędu wypełniania potoku. |
| Serwer wywołuje wypychanie lub ściąganie, a wywołanie kończy się niepowodzeniem. | Wypychanie zwraca kod błędu. Nie jest konieczne wywołanie RpcAsyncCompleteCall. |
| Serwer wywołuje RpcAsyncCompleteCall przed opróżnienie potoków. | Wywołanie potoku zwraca stan błędu wypełniania potoku. |
| Po wysłaniu operacja odbierania zakończy się niepowodzeniem. | Następnym razem, gdy serwer wywołuje metodę pull w celu odbierania danych potoku, zostanie zwrócony błąd. |