Share via

Gestion des erreurs et valeurs de retour

  • Article

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 ISupportErrorInfonormalement . 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ée ErrorInfo d’une fonction ou lors du retour S_OK. La seule exception à cette règle est lorsqu’un appel retourne une erreur HRESULT à 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’objet ErrorInfo peut être utilisé accidentellement lorsqu’une autre partie génère une erreur sans fournir sa propre erreur ErrorInfo.

  • 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 retour HRESULT est une erreur spéciale FACILITY_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 erreur HRESULT (y compris les erreurs système), appelez toujours la SetErrorInfo méthode, soit avec ErrorInfo la description de l’échec plus en détail, soit null.

  • 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’objet ErrorInfo .

Voir aussi