Condividi tramite

Gestione degli errori (RPC)

  • Articolo

In RPC sincrono, un client esegue una chiamata remota che restituisce con un codice di esito positivo o negativo. RPC asincrono offre più opportunità per un errore di chiamata e questi errori vengono gestiti in modo diverso, a seconda di dove e quando si verificano. La tabella seguente descrive i modi in cui una chiamata può avere esito negativo e come viene gestito.

Pulizia lato client

Sintomo di errore Pulizia
Il client rileva un'eccezione quando chiama la procedura remota. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Il client riceve una notifica completa della chiamata, ma quando chiama RpcAsyncCompleteCall, riceve un codice di errore. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Problemi client non abortivi o annullamenti interrotti. Il client deve attendere la notifica e chiamare RpcAsyncCompleteCall quando arriva la notifica.

 

Nella pulizia lato server, un concetto chiave è il punto di off-off. Durante l'elaborazione lato server di una chiamata asincrona, alcune elaborazioni vengono in genere eseguite sul thread che ha ricevuto la chiamata (noto anche come thread dispatcher) e quindi, facoltativamente, il thread dispatcher inserisce uno stato sufficiente in un blocco di memoria e segnala un altro thread (noto anche come thread di lavoro) per continuare l'elaborazione per la chiamata. Il momento in cui il thread dispatcher segnala correttamente che il thread di lavoro viene chiamato punto di off-off.

Pulizia lato server

Errore rilevato Pulizia
Prima di passare il punto. Generare un'eccezione. Non è necessaria alcuna chiamata a RpcAsyncCompleteCall .
Dopo il punto di partenza. Chiamare RpcAsyncAbortCall o, se l'errore non è irreversibile e i risultati possono comunque essere restituiti al client, RpcAsyncCompleteCall. Se la chiamata di funzione RpcAsyncCompleteCall ha esito negativo, il runtime RPC libera i parametri. L'utente non deve accedere a tali parametri. Il thread dispatcher non deve eseguire alcuna elaborazione sostanziale che potrebbe non riuscire dopo il punto di interruzione della mano, perché non può più interrompere in modo sicuro la chiamata. In particolare, non deve generare un'eccezione dopo il punto di disattivazione della mano o il server potrebbe arrestarsi in modo anomalo.

 

Casi di gestione degli errori speciali per pipe

Esistono casi speciali per la gestione degli errori durante l'uso di pipe. L'elenco seguente illustra l'origine dell'errore e come gestire l'errore.

Origine dell'errore Come viene gestito
Chiamate client push e la chiamata ha esito negativo. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Il client chiama RpcAsyncCompleteCall prima che le pipe vengano svuotate. La chiamata ha esito negativo con il codice di errore di riempimento della pipe appropriato.
Chiamate client pull e la chiamata ha esito negativo. Non sono necessarie chiamate API RPC. Tutti gli stati RPC sono stati puliti.
Il client o il server chiamano il push o il pull nell'ordine errato. Run-time restituisce lo stato di errore di riempimento della pipe.
Il server chiama push o pull e la chiamata ha esito negativo. Il push restituisce un codice di errore. Non è necessaria alcuna chiamata a RpcAsyncCompleteCall .
Il server chiama RpcAsyncCompleteCall prima che le pipe siano state svuotate. La chiamata pipe restituisce uno stato di errore di riempimento della pipe.
Dopo l'invio, un'operazione di ricezione ha esito negativo. La prossima volta che il server chiama pull per ricevere i dati della pipe, viene restituito un errore.