Fehlerbehandlung (RPC)
In synchronem RPC wird von einem Client ein Remoteaufruf ausgeführt, der entweder mit einem Erfolgs- oder Fehlercode zurückgegeben wird. Asynchroner RPC bietet mehr Möglichkeiten für einen Fehleraufruf, und diese Fehler werden je nach Ort und Wann unterschiedlich behandelt. In der folgenden Tabelle werden die Möglichkeiten 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 rpc-Status wurde bereinigt. |
| Der Client empfängt eine Benachrichtigung zum Abschluss des Aufrufs, aber wenn er RpcAsyncCompleteCall aufruft,erhält er einen Fehlercode. | Es sind keine RPC-API-Aufrufe erforderlich. Der rpc-Status wurde bereinigt. |
| Der Client gibt einen nicht abortiven oder abortiven Abbruch aus. | Der Client muss auf eine Benachrichtigung warten und RpcAsyncCompleteCall aufrufen, wenn die Benachrichtigung eintrifft. |
Bei der serverseitigen Bereinigung ist ein schlüsselorientiertes Konzept der Übergabepunkt. Während der serverseitigen Verarbeitung eines asynchronen Aufrufs wird in der Regel ein Teil der Verarbeitung für den Thread ausgeführt, der den Aufruf empfangen hat (auch als Verteilerthread bezeichnet). Optional legt der Verteilerthread genügend Zustand in einen Speicherblock ein und signalisiert einem anderen Thread (auch als Arbeitsthread bezeichnet), um die Verarbeitung für den Aufruf fortzufahren. Der Moment, an dem der Verteilerthread erfolgreich signalisiert, dass der Arbeitsthread als Übergabepunkt bezeichnet wird.
Serverseitige Bereinigung
| Fehler aufgetreten | Cleanup |
|---|---|
| Vor dem Übergabepunkt. | Ausnahme auslösen. Es ist kein Aufruf von RpcAsyncCompleteCall erforderlich. |
| Nach dem Übergabepunkt. | Rufen Sie RpcAsyncAbortCall auf, oder , wenn der Fehler nicht schwerwiegender ist und ergebnisse weiterhin an den Client zurückgegeben werden können, RpcAsyncCompleteCall. Wenn der RpcAsyncCompleteCall-Funktionsaufruf fehlschlägt, gibt die RPC-Laufzeit die Parameter frei. Der Benutzer darf nicht auf diese Parameter zugreifen. Der Verteilerthread darf keine wesentliche Verarbeitung durchführen, die nach dem Übergabepunkt fehlschlagen kann, 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 Pipes
Es gibt Sonderfälle für die Fehlerbehandlung bei der Verwendung von Pipes. In der folgenden Liste werden die Fehlerquelle und die Fehlerbehandlung erläutert.
| Fehlerquelle | Wie behandelt wird |
|---|---|
| Der Client ruft push auf, und der Aufruf schlägt fehl. | Es sind keine RPC-API-Aufrufe erforderlich. Der rpc-Status wurde bereinigt. |
| Der Client ruft RpcAsyncCompleteCall auf, bevor die in-Pipes entleert werden. | Der Aufruf schlägt mit dem entsprechenden Pipefüllfehlercode fehl. |
| Der Client ruft pull auf, und der Aufruf schlägt fehl. | Es sind keine RPC-API-Aufrufe erforderlich. Der rpc-Status wurde bereinigt. |
| Entweder der Client oder Der Server ruft Push oder Pull in der falschen Reihenfolge auf. | Die Laufzeit gibt den Fehlerstatus der Pipefüllung zurück. |
| Der Server ruft Push oder Pull auf, und der Aufruf schlägt fehl. | Push gibt einen Fehlercode zurück. Es ist kein Aufruf von RpcAsyncCompleteCall erforderlich. |
| Der Server ruft RpcAsyncCompleteCall auf, bevor die Pipes entleert wurden. | Der Pipeaufruf gibt einen Pipefüllfehlerstatus 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. |