Stratégies de gestion des erreurs dans COM+
Cette rubrique présente plusieurs stratégies de gestion des erreurs à garder à l'esprit lorsque vous développez des composants pour COM+.
Renvoyez une valeur HRESULT pour toutes les méthodes de toutes les interfaces de composants. COM+ utilise les valeurs HRESULT pour signaler toute erreur dans les appels de fonction ou de méthode d'interface. Un HRESULT indique si une méthode a réussi ou échoué et identifie la facilité associée à l'erreur, telle que RPC, WIN32 ou ITF pour les erreurs spécifiques à l'interface. En outre, les API du système permettent de passer d'un HRESULT à une chaîne de caractères décrivant la condition d'erreur. L'utilisation de méthodes renvoyant des valeurs HRESULT est fondamentale pour les composants bien écrits et est essentielle au processus de débogage. Microsoft Visual Basic définit automatiquement chaque méthode avec un HRESULT comme retour. Dans Microsoft Visual C++, vous devez renvoyer explicitement un HRESULT. Pour plus d'informations sur les HRESULTES, voir la structure des codes d'erreur COM.
Lancez l'objet de collecte ErrorInfo par n'importe quel moyen fourni par votre outil de développement. Les objets de collecte ErrorInfo sont souvent appelés exceptions COM car ils permettent à un objet de transmettre (ou de jeter) des informations d'erreur riches à son appelant, même au-delà des limites d'un appartement. L'intérêt de cet objet d'erreur générique est qu'il complète un HRESULT, élargissant ainsi le type d'informations d'erreur que vous pouvez renvoyer à un appelant. Chaque objet de la collection ErrorInfo renvoie une description contextuelle, la source de l'erreur et l'identifiant d'interface de la méthode à l'origine de l'erreur. Vous pouvez également inclure des pointeurs vers une entrée dans un fichier d'aide. L'automatisation fournit trois interfaces pour gérer l'objet d'erreur. Votre composant doit implémenter l'interface d'automatisation ISupportErrorInfo pour annoncer sa prise en charge de la collection ErrorInfo. Lorsqu'une erreur survient, le composant utilise l'interface d'automatisation ICreateErrorInfo pour initialiser un objet d'erreur. Lorsque l'appelant inspecte le HRESULT et constate que l'appel de la méthode a échoué, il demande à l'objet s'il prend en charge la collection ErrorInfo. Si c'est le cas, l'appelant utilise l'interface IErrorInfo Automation pour récupérer les informations relatives à l'erreur. Les programmeurs Visual Basic ont facilement accès à la collection d'objets ErrorInfo, qui est exposée à travers l'objet Err. Vous pouvez lever les erreurs à l'aide de la fonction Err Raise et les rattraper à l'aide de l'instruction On Error. La couche d'exécution Visual Basic se charge du mappage pour vous. Si vous utilisez le support du compilateur Visual C++ COM, vous pouvez utiliser la classe _com_raise_error pour signaler une erreur et la classe _com_error pour récupérer les informations d'erreur. COM+ ne propagera pas les exceptions C++ traditionnelles en tant qu'informations IErrorInfo étendues. Pour plus d'informations sur l'objet de collection ErrorInfo, voir « Gestion des erreurs » dans le guide d'automatisation.
Remarque
COM exige que tous les objets de collection ErrorInfo soient marshalés par valeur, ce qui implique que les composants qui mettent en œuvre l'interface IErrorInfo Automation doivent également mettre en œuvre et prendre en charge l'interface IMarshal. L'implémentation de l'interface IMarshal doit prendre en charge le marshal par valeur pour le composant.
Utilisez les transactions pour gérer les défaillances des ressources partagées. Les transactions automatiques peuvent réduire de manière significative la quantité de code de gestion des erreurs que vous devez écrire lorsque vous utilisez des gestionnaires de ressources gérés par état. Cependant, les transactions n'éliminent pas complètement la nécessité de gérer les erreurs. Vous devez toujours renvoyer des codes d'erreur à partir de vos méthodes d'interface et vérifier ces codes d'erreur au sein de l'appelant afin d'éviter d'effectuer un travail inutile pour une transaction condamnée. Pour plus d'informations sur la combinaison de la gestion des erreurs avec le traitement des transactions, voir Accélérer les transactions en notifiant l'objet racine.
Faites remonter les erreurs de manière explicite. Évitez de laisser des informations d'erreur quitter un objet à moins que l'objet ne lève explicitement l'erreur. Attrapez toutes les erreurs générées par l'outil et traitez-les dans le code de votre composant. Au minimum, incluez un gestionnaire standard pour signaler les erreurs inattendues de manière cohérente.
Utilisez la plage d'erreurs FACILITY_ITF pour signaler les erreurs spécifiques à l'interface. Les erreurs spécifiques à l'interface doivent se situer dans la plage d'erreurs FACILITY_ITF, entre 0x0200 et 0xFFFF. Vous pouvez définir un code d'erreur personnalisé en Visual Basic en tant que décalage de vbObjectError. Utilisez la macro MAKE_HRESULT en C++ pour introduire un code d'erreur spécifique à l'interface, comme le montre l'exemple suivant :
const HRESULT ERROR_NUMBER = MAKE_HRESULT (SEVERITY_ERROR, FACILITY_ITF, 10);
Rubriques connexes