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 [out] spécial qui retourne le code d’erreur. Cela conduit à des interfaces implémentées de la manière 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. Elles n’ont pas de signification particulière en tant qu’erreurs (notez que error_status_t n’a pas de sémantique spéciale côté serveur), ce qui a des implications importantes.

Tout d’abord, RPC n’est pas averti que l’opération a échoué ; il tente d’annuler 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 enfoui 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 déterminer où l’appel a échoué.

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

Gestion des exceptions