Fehlerbehandlung (RPC)

Bei synchronem RPC führt ein Client einen Remoteaufruf aus, der entweder mit einem Erfolgs- oder Fehlercode zurückgibt. Asynchrone RPC bietet mehr Möglichkeiten für einen Fehlschlagen eines Aufrufs, und diese Fehler werden unterschiedlich behandelt, je nachdem, wo und wann sie auftreten. In der folgenden Tabelle wird beschrieben, wie ein Aufruf fehlschlagen kann und wie er behandelt wird.

Clientseitige Bereinigung

Fehlersymptom	Cleanup
Der Client fängt eine Ausnahme ab, wenn er die Remoteprozedur aufruft.	Es sind keine RPC-API-Aufrufe erforderlich. Der gesamte RPC-Status wurde bereinigt.
Der Client erhält eine Benachrichtigung zum Abschließen des Anrufs, aber wenn er RpcAsyncCompleteCall aufruft, erhält er einen Fehlercode.	Es sind keine RPC-API-Aufrufe erforderlich. Der gesamte RPC-Status wurde bereinigt.
Der Client gibt einen nicht abgebrochenen oder abgebrochenen Abbruch aus.	Der Client muss auf eine Benachrichtigung warten und RpcAsyncCompleteCall aufrufen, wenn die Benachrichtigung eingeht.

 

Bei der serverseitigen Bereinigung ist ein wichtiges Konzept der Übergabepunkt. Während der serverseitigen Verarbeitung eines asynchronen Aufrufs erfolgt eine verarbeitung in der Regel für den Thread, der den Aufruf empfangen hat (auch als Verteilerthread bezeichnet), und optional fügt der Verteilerthread einen ausreichenden Zustand in einen Speicherblock ein und signalisiert einem anderen Thread (auch als Workerthread bezeichnet), die Verarbeitung für den Aufruf fortzusetzen. Der Zeitpunkt, zu dem der Dispatcherthread erfolgreich signalisiert, dass der Workerthread als Übergabepunkt bezeichnet wird.

Serverseitige Bereinigung

Fehler aufgetreten	Cleanup
Vor dem Übergabepunkt.	Löst eine Ausnahme aus. Es ist kein Aufruf von RpcAsyncCompleteCall erforderlich.
Nach dem Übergabepunkt.	Rufen Sie RpcAsyncAbortCall oder rpcAsyncCompleteCall auf, wenn der Fehler nicht schwerwiegend ist und Ergebnisse weiterhin an den Client zurückgegeben werden können. Wenn der RpcAsyncCompleteCall-Funktionsaufruf fehlschlägt, gibt die RPC-Runtime die Parameter frei. Der Benutzer darf nicht auf diese Parameter zugreifen. Der Verteilerthread darf keine wesentliche Verarbeitung durchführen, die nach dem Übergabepunkt möglicherweise fehlschlägt, da er den Aufruf nicht mehr sicher abbrechen kann. Insbesondere darf nach dem Übergabepunkt keine Ausnahme ausgelöst werden, da der Server möglicherweise abstürzt.

 

Spezielle Fehlerbehandlungsfälle für Rohre

Es gibt spezielle Fälle für die Fehlerbehandlung bei der Verwendung von Pipes. In der folgenden Liste werden die Fehlerursache und die Behandlung des Fehlers erläutert.

Fehlerquelle	Wie wird gehandhabt?
Clientaufrufe pushen, und der Anruf schlägt fehl.	Es sind keine RPC-API-Aufrufe erforderlich. Der gesamte RPC-Status wurde bereinigt.
Der Client ruft RpcAsyncCompleteCall auf, bevor die in Pipes entladen werden.	Der Aufruf schlägt mit dem entsprechenden Pipefüllfehlercode fehl.
Clientaufrufe pullen, und der Anruf schlägt fehl.	Es sind keine RPC-API-Aufrufe erforderlich. Der gesamte RPC-Status wurde bereinigt.
Client- oder Serveraufrufe pushen oder pullen in der falschen Reihenfolge.	Die Laufzeit gibt einen Pipefüllfehler status zurück.
Serveraufrufe per Push oder Pull, und der Anruf schlägt fehl.	Push gibt einen Fehlercode zurück. Es ist kein Aufruf von RpcAsyncCompleteCall erforderlich.
Der Server ruft RpcAsyncCompleteCall auf, bevor die Pipes geleert wurden.	Der Pipeaufruf gibt einen Pipefüllfehler status zurück.
Nach der Versendung schlägt ein Empfangsvorgang fehl.	Wenn der Server das nächste Mal pull aufruft, um Pipedaten zu empfangen, wird ein Fehler zurückgegeben.