Gestion des erreurs et valeurs de retour
VSPackages et COM utilisent la même architecture pour les erreurs. Les SetErrorInfo
fonctions et GetErrorInfo
les fonctions font partie de l’interface de programmation d’applications Win32 (API). Tout VSPackage dans l’environnement de développement intégré (IDE) peut appeler ces API Win32 globales pour enregistrer des informations d’erreur enrichies lors de la réception d’une notification d’erreur. Le Kit de développement logiciel (SDK) Visual Studio fournit des assemblys d’interopérabilité pour gérer les informations d’erreur.
Méthodes d’interopérabilité
En guise de commodité, l’IDE fournit une méthode, SetErrorInfoà utiliser au lieu d’appeler les API Win32. Dans le code managé, utilisez SetErrorInfo. Lorsqu’une erreur arrive au niveau où le message d’erreur HRESULT
doit être affiché (il s’agit souvent de l’objet implémentant un IOleCommandTarget gestionnaire de commandes), l’IDE utilise une autre méthode, ReportErrorInfopour afficher la zone de message appropriée. Dans le code managé, utilisez la ReportErrorInfo méthode.
En tant qu’implémenteur VSPackage, vos objets COM implémentent ISupportErrorInfo
normalement . L’interface ISupportErrorInfo
garantit que les informations d’erreur enrichies peuvent se déplacer verticalement vers le haut de la chaîne d’appels. Les objets qui peuvent être utilisés entre les processus ou les threads doivent être pris en charge ISupportErrorInfo
pour s’assurer que les informations d’erreur enrichies sont correctement marshalées sur l’appelant.
Tous les objets liés aux VSPackages et qui sont impliqués dans l’extension de l’IDE, y compris les fabriques d’éditeurs, les éditeurs, les hiérarchies et les services proposés, doivent prendre en charge des informations d’erreur enrichies. Bien que l’IDE ne nécessite pas que ces objets VSPackage soient implémentés ISupportErrorInfo
, il est toujours encouragé.
L’IDE est chargé de signaler les informations d’erreur et de l’afficher à un utilisateur de Visual Studio chaque fois qu’une HRESULT
extension est propagée à l’IDE. L’IDE est également le mécanisme de création d’objets ErrorInfo
.
Recommandations générales
Vous pouvez également utiliser les méthodes et ReportErrorInfo les SetErrorInfo méthodes pour définir et signaler des erreurs internes à votre implémentation VSPackage. Toutefois, en règle générale, suivez ces instructions pour gérer les messages d’erreur dans votre VSPackage :
Implémentez
ISupportErrorInfo
dans vos objets COM VSPackage.Créez un mécanisme de création de rapports d’erreurs qui appelle la SetErrorInfo méthode dans les objets qui implémentent IOleCommandTarget.
Laissez l’IDE afficher les erreurs aux utilisateurs par le biais de la ReportErrorInfo méthode.
Informations d’erreur dans l’IDE
Les règles suivantes indiquent comment gérer les informations d’erreur dans l’IDE Visual Studio :
En tant que stratégie défensive pour garantir que les informations d’erreur obsolètes ne sont pas signalées aux utilisateurs, les fonctions qui appellent la ReportErrorInfo méthode doivent d’abord appeler la SetErrorInfo méthode. Passez-y
null
pour effacer les messages d’erreur mis en cache avant d’appeler tout ce qui peut définir de nouvelles informations d’erreur.Les fonctions qui ne signalent pas directement les messages d’erreur sont uniquement autorisées à appeler la SetErrorInfo méthode s’ils retournent une erreur
HRESULT
. Il est permis d’effacer l’entréeErrorInfo
d’une fonction ou lors du retour S_OK. La seule exception à cette règle est lorsqu’un appel retourne une erreurHRESULT
à partir de laquelle la partie de réception peut récupérer explicitement ou ignorer en toute sécurité.Toute partie qui ignore explicitement une erreur
HRESULT
doit appeler la SetErrorInfo méthode avec S_OK. Sinon, l’objetErrorInfo
peut être utilisé accidentellement lorsqu’une autre partie génère une erreur sans fournir sa propre erreurErrorInfo
.Toutes les méthodes qui proviennent d’une erreur
HRESULT
sont encouragées à appeler la SetErrorInfo méthode pour fournir des informations d’erreur enrichies. Si le retourHRESULT
est une erreur spécialeFACILITY_ITF
, la méthode est nécessaire pour fournir un objet appropriéErrorInfo
. Si l’erreur retournée est une erreur système standard (par exemple, E_OUTOFMEMORY, , E_ABORTE_INVALIDARG, E_UNEXPECTEDet ainsi de suite).) il est acceptable de retourner le code d’erreur sans appeler explicitement la SetErrorInfo méthode. En tant que stratégie de codage défensif, lors de l’origine d’une erreurHRESULT
(y compris les erreurs système), appelez toujours la SetErrorInfo méthode, soit avecErrorInfo
la description de l’échec plus en détail, soitnull
.Toutes les fonctions qui retournent une erreur proviennent d’un autre appel doivent transmettre les informations reçues de l’appel défaillant sans
HRESULT
modifier l’objetErrorInfo
.