Partager via

Indiquer les erreurs par exceptions

  • Article

Pour les programmeurs C traditionnels, les erreurs sont généralement retournées par le biais de valeurs de retour ou d’un paramètre spécial [out] qui retourne le code d’erreur. Cela conduit à des interfaces implémentées de la façon suivante :

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

Le problème avec cette approche est que les valeurs de retour RPC sont simplement des entiers longs. Ils n’ont pas de signification spéciale en tant qu’erreurs (notez que error_status_t n’a aucune sémantique spéciale côté serveur), ce qui porte des implications importantes.

Tout d’abord, RPC n’est pas averti que l’opération a échoué ; il tente de démarshaler tous les arguments [in, out] et [out]. La sémantique d’échec des handles de contexte est également différente. Le paquet retourné au client est essentiellement un paquet de réussite, avec le code d’erreur enterré dans le paquet. Cela signifie également que RPC n’utilise pas d’informations d’erreur étendues, de sorte que le logiciel client est souvent incapable de discerner où l’appel a échoué.

L’indication d’erreurs dans les routines de serveur RPC en lève des exceptions SEH (Structured Exception Handling) (et non C++) est une approche bien meilleure. Lorsqu’une exception SEH est levée, le contrôle passe directement à l’heure d’exécution RPC. Une erreur se produit parfois profondément dans une routine qui ne peut pas nettoyer correctement, et il doit indiquer une erreur à son appelant. La routine doit renvoyer une erreur à son appelant, qui à son tour peut renvoyer une erreur à son appelant, et ainsi de suite. Toutefois, la dernière routine de serveur sur la pile doit lever une exception avant de revenir à RPC pour indiquer à RPC qu’une erreur s’est produite.

gestion des exceptions