Comment : mapper des HRESULT et des exceptions

Mise à jour : novembre 2007

Les méthodes COM signalent les erreurs en retournant des valeurs HRESULT ; les méthodes .NET les signalent en levant des exceptions. Le runtime gère la transition entre les deux. Chaque classe d'exception dans le .NET Framework est mappée à une valeur HRESULT.

Les classes d'exceptions définies par l'utilisateur peuvent spécifier la valeur HRESULT appropriée. Ces classes d'exceptions peuvent modifier dynamiquement la valeur HRESULT à retourner quand l'exception est générée par la définition du champ HResult sur l'objet exception. Des informations supplémentaires relatives à l'exception sont fournies par le biais de l'interface IErrorInfo, qui est implémentée sur l'objet .NET dans le processus non managé.

Si vous créez une classe qui étend System.Exception, vous devez définir le champ HRESULT pendant la construction. Sinon, la classe de base assigne la valeur HRESULT. Vous pouvez mapper de nouvelles classes d'exceptions à un HRESULT existant en fournissant la valeur dans le constructeur de l'exception.

Notez que l'exécution ignorera parfois un HRESULT si le thread comporte un IErrorInfo. Ce comportement peut se présenter si HRESULT et IErrorInfo ne représentent pas la même erreur.

Pour créer une classe d'exception et la mapper à un HRESULT

• Utilisez le code suivant pour créer une classe d'exception appelée NoAccessException et la mapper à E_ACCESSDENIED du HRESULT.

  Class NoAccessException : public ApplicationException
  {
      NoAccessException () {
      HResult = E_ACCESSDENIED; 
  }
  }
  CMyClass::MethodThatThrows
  {
  throw new NoAccessException();
  }
  

Vous pouvez rencontrer un programme (écrit dans n'importe quel langage de programmation) qui utilise à la fois un code managé et un code non managé en même temps. Par exemple, le marshaleur personnalisé dans l'exemple de code suivant utilise la méthode Marshal.ThrowExceptionForHR(int HResult) pour lever une exception avec une valeur HRESULT spécifique. La méthode consulte HRESULT et génère le type d'exception approprié. Par exemple, dans le fragment de code suivant, HRESULT génère ArgumentException.

CMyClass::MethodThatThrows
{
    Marshal.ThrowExceptionForHR(COR_E_ARGUMENT);
}

Le tableau suivant fournit le mappage complet à partir de chaque HRESULT vers sa classe d'exception comparable dans le .NET Framework.

Pour extraire des informations d'erreur étendues, le client managé doit examiner les champs de l'objet exception généré. Pour que l'objet exception fournisse des informations utiles sur une erreur, l'objet COM doit implémenter l'interface IErrorInfo. Le runtime utilise les informations fournies par IErrorInfo pour initialiser l'objet exception.

Si l'objet COM ne prend pas en charge IErrorInfo, le runtime initialise un objet exception avec les valeurs par défaut. Le tableau suivant répertorie chaque champ associé à un objet exception et identifie la source des informations par défaut lorsque l'objet COM prend en charge IErrorInfo.

Notez que l'exécution ignorera parfois un HRESULT si le thread comporte un IErrorInfo. Ce comportement peut se présenter si HRESULT et IErrorInfo ne représentent pas la même erreur.

Les champs d'exception, tels que Message, Source et StackTrace ne sont pas disponibles pour StackOverflowException.

Voir aussi

Autres ressources

Interopérabilité COM avancée

Gestion et levée des exceptions