Indicar errores por excepciones
En el caso de los programadores de C tradicionales, los errores se devuelven normalmente a través de valores devueltos o un parámetro [out] especial que devuelve el código de error. Esto conduce a interfaces implementadas de la siguiente manera:
long sample(...)
{
...
p = new Cbar(...);
if (p == NULL)
{
// cleanup
...
return ERROR_OUTOFMEMORY;
}
}
El problema con este enfoque es que los valores devueltos de RPC son simplemente enteros largos. No tienen ningún significado especial como errores (tenga en cuenta que error_status_t no tiene semántica especial en el lado servidor), lo que conlleva implicaciones importantes.
En primer lugar, RPC no recibe una alerta de que se produjo un error en la operación; intenta desenlamarar todos los argumentos [in, out] y [out]. La semántica de errores de los identificadores de contexto también son diferentes. El paquete devuelto al cliente es básicamente un paquete correcto, con el código de error enterrado en profundidad en el paquete. Esto también significa que RPC no usa información de error extendida, por lo que el software cliente a menudo no puede distinguir dónde se produjo un error en la llamada.
La indicación de errores en las rutinas del servidor RPC al iniciar excepciones de control de excepciones estructurados (no SEH) es un enfoque mucho mejor. Cuando se produce una excepción SEH, el control pasa directamente al tiempo de ejecución de RPC. A veces, un error se produce en profundidad en una rutina que no se puede limpiar correctamente y debe indicar un error a su autor de la llamada. La rutina debe devolver un error a su llamador, que a su vez puede devolver un error a su llamador, etc. Sin embargo, la última rutina de servidor de la pila debe producir una excepción antes de volver a RPC para indicar a RPC que se produjo un error.
Temas relacionados