Partager via


Utilisation de handles de liaison et appels RPC

Une erreur courante parmi les programmeurs RPC est la gestion de toutes les exceptions. De nombreux programmeurs structurent leurs handles d’exception comme suit :

    RpcTryExcept
        {
        RemoteSample();
        }
    RpcExcept(1)
        {
        log an error or do something else
        }
    RpcEndExcept

Le problème avec ce gestionnaire est qu’il intercepte toutes les erreurs, y compris les erreurs dans le programme client. L’interception des erreurs dans le programme client rend le débogage plus difficile. La méthode appropriée pour structurer un gestionnaire d’exceptions est la suivante :

    RpcTryExcept
        {
        RemoteSample();
        }
    // Return "non-fatal" errors to clients.  Catching fatal errors
    // makes it harder to debug.
    RpcExcept( ( ( (RpcExceptionCode() != STATUS_ACCESS_VIOLATION) &&
                   (RpcExceptionCode() != STATUS_POSSIBLE_DEADLOCK) &&
                   (RpcExceptionCode() != STATUS_INSTRUCTION_MISALIGNMENT) &&
                   (RpcExceptionCode() != STATUS_DATATYPE_MISALIGNMENT) &&
                   (RpcExceptionCode() != STATUS_PRIVILEGED_INSTRUCTION) &&
                   (RpcExceptionCode() != STATUS_ILLEGAL_INSTRUCTION) &&
                   (RpcExceptionCode() != STATUS_BREAKPOINT) &&
                   (RpcExceptionCode() != STATUS_STACK_OVERFLOW) &&
                   (RpcExceptionCode() != STATUS_HANDLE_NOT_CLOSABLE) &&
                   (RpcExceptionCode() != STATUS_IN_PAGE_ERROR) &&
                   (RpcExceptionCode() != STATUS_ASSERTION_FAILURE) &&
                   (RpcExceptionCode() != STATUS_STACK_BUFFER_OVERRUN) &&
                   (RpcExceptionCode() != STATUS_GUARD_PAGE_VIOLATION)
                    )
                    ? EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH ) )
        {
        log an error or do something else
        }
    RpcEndExcept

Ce gestionnaire d’exceptions présente l’avantage de laisser passer une certaine plage d’erreurs. Ces erreurs ne seront jamais retournées par le serveur, car elles indiquent un problème côté client.

En outre, l’utilisation des attributs [strict_context_handle] et [type_strict_context_handle] est recommandée pour s’assurer que l’exécution RPC crée un handle de contexte sur une interface qui peut être passé en tant qu’argument uniquement aux méthodes de cette interface. Cela permet d’éviter les défaillances de serveur qui se produisent lorsque des handles de contexte sont ouverts et passés entre différentes interfaces qui existent dans le même processus.

strict_context_handle

type_strict_context_handle