Compartilhar via

Indicar erros por exceções

  • Artigo

Para programadores C tradicionais, os erros normalmente são retornados por meio de valores retornados ou um parâmetro [out] especial que retorna o código de erro. Isso leva a interfaces implementadas da seguinte maneira:

long sample(...)
{
    ...
    p = new Cbar(...);
    if (p == NULL)
    {
        // cleanup
        ...
        return ERROR_OUTOFMEMORY;
    }
}

O problema com essa abordagem é que os valores retornados de RPC são simplesmente inteiros longos. Eles não têm nenhum significado especial como erros (observe que error_status_t não tem semântica especial no lado do servidor), o que traz implicações importantes.

Primeiro, o RPC não é alertado de que a operação falhou; ele tenta cancelar omarsal de todos os argumentos [in, out] e [out]. A semântica de falha dos identificadores de contexto também é diferente. O pacote retornado ao cliente é essencialmente um pacote de êxito, com o código de erro enterrado profundamente no pacote. Isso também significa que o RPC não usa informações de erro estendidas, portanto, o software cliente geralmente não consegue discernir onde a chamada falhou.

Indicar erros em rotinas de servidor RPC gerando exceções seh (tratamento de exceções estruturadas) (não C++) é uma abordagem muito melhor. Quando uma exceção SEH é gerada, o controle vai diretamente para o tempo de execução de RPC. Às vezes, ocorre um erro profundo em uma rotina que não pode limpo corretamente e precisa indicar um erro para o chamador. A rotina deve retornar um erro ao chamador, que, por sua vez, pode retornar um erro ao chamador e assim por diante. No entanto, a última rotina de servidor na pilha deve gerar uma exceção antes de retornar ao RPC para indicar ao RPC que ocorreu um erro.

Tratamento de exceção