Control de errores (RPC)

En RPC sincrónica, un cliente realiza una llamada remota que devuelve con un código correcto o de error. RPC asincrónico proporciona más oportunidades para que se produzca un error en una llamada, y estos errores se controlan de forma diferente, en función de dónde y cuándo se produzcan. En la tabla siguiente se describen las formas en que se puede producir un error en una llamada y cómo se controla.

Limpieza del lado cliente

Síntoma de error	Limpieza
El cliente detecta una excepción cuando llama al procedimiento remoto.	No es necesario llamar a la API rpc. Se ha limpiado todo el estado rpc.
El cliente recibe una notificación completa de llamada, pero cuando llama a RpcAsyncCompleteCall, recibe un código de error.	No es necesario llamar a la API rpc. Se ha limpiado todo el estado rpc.
El cliente emite una cancelación no anulativa o anulación.	El cliente debe esperar la notificación y llamar a RpcAsyncCompleteCall cuando llegue la notificación.

 

En la limpieza del lado servidor, un concepto clave es el punto de entrega. Durante el procesamiento del lado servidor de una llamada asincrónica, se suele realizar algún procesamiento en el subproceso que recibió la llamada (también conocido como subproceso del distribuidor) y, opcionalmente, el subproceso del distribuidor coloca suficiente estado en un bloque de memoria y señala otro subproceso (también conocido como subproceso de trabajo) para continuar el procesamiento de la llamada. El momento en el que el subproceso del distribuidor señala correctamente que el subproceso de trabajo se denomina punto de entrega.

Limpieza del lado servidor

Error detectado	Limpieza
Antes del punto de entrega.	Iniciar excepción. No es necesario llamar a RpcAsyncCompleteCall .
Después del punto de entrega.	Llame a RpcAsyncAbortCall o, si el error no es grave y los resultados todavía se pueden devolver al cliente , RpcAsyncCompleteCall. Si se produce un error en la llamada a la función RpcAsyncCompleteCall , el tiempo de ejecución rpc libera los parámetros. El usuario no debe tener acceso a esos parámetros. El subproceso del distribuidor no debe realizar ningún procesamiento sustancial que pueda producir un error después del punto de entrega, ya que ya no puede anular la llamada de forma segura. En concreto, no debe producir una excepción después del punto de entrega o el servidor puede bloquearse.

 

Casos especiales de control de errores para canalizaciones

Hay casos especiales para el control de errores al usar canalizaciones. En la lista siguiente se explica el origen del error y cómo controlar el error.

Origen de error	Cómo se controla
El cliente llama a push y se produce un error en la llamada.	No es necesario llamar a la API rpc. Se ha limpiado todo el estado rpc.
El cliente llama a RpcAsyncCompleteCall antes de que se desagüen las canalizaciones.	Se produce un error en la llamada con el código de error de relleno de canalización adecuado.
Las llamadas de cliente se extraen y se produce un error en la llamada.	No es necesario llamar a la API rpc. Se ha limpiado todo el estado rpc.
El cliente o el servidor llaman a insertar o extraer en el orden incorrecto.	El tiempo de ejecución devuelve el estado de error de relleno de canalización.
El servidor llama a inserción o extracción y se produce un error en la llamada.	Push devuelve un código de error. No es necesario llamar a RpcAsyncCompleteCall .
El servidor llama a RpcAsyncCompleteCall antes de que se hayan purgado las canalizaciones.	La llamada de canalización devuelve un estado de error de relleno de canalización.
Después del envío, se produce un error en una operación de recepción.	La próxima vez que el servidor llame a pull para recibir datos de canalización, se devuelve un error.