Procedura: eseguire il mapping di HRESULT ed eccezioni

Aggiornamento: novembre 2007

Per segnalare il verificarsi di un errore, i metodi COM restituiscono un HRESULT. I metodi .NET, invece, generano un'eccezione. Il runtime gestisce la transizione tra i due. Ogni classe che identifica un'eccezione in .NET Framework è associata a un HRESULT.

Le classi di eccezione definite dall'utente possono specificare un HRESULT appropriato. Impostando il campo HResult dell'oggetto di eccezione, tali classi di eccezione possono modificare dinamicamente l'HRESULT che deve essere restituito quando viene generata l'eccezione. Informazioni aggiuntive sull'eccezione vengono fornite al client tramite l'interfaccia IErrorInfo, che è implementata dall'oggetto .NET nel processo non gestito.

Se si crea una classe che estende System.Exception, sarà necessario impostare il campo HRESULT durante la costruzione. In caso contrario, sarà la classe base a assegnare il valore di HRESULT. È possibile associare nuove classi di eccezione a un HRESULT esistente fornendo il valore nel costruttore dell'eccezione.

Si noti che talvolta un HRESULT può essere ignorato dal runtime quando è presente un'interfaccia IErrorInfo sul thread. Questo comportamento può verificarsi nei casi in cui l'HRESULT e l'interfaccia IErrorInfo non rappresentano lo stesso errore.

Per creare una nuova classe di eccezione e mapparla a un HRESULT

• Utilizzare il codice seguente per creare una nuova classe di eccezione denominata NoAccessException e mapparla al HRESULT E_ACCESSDENIED.

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

È possibile imbattersi in un programma (in qualsiasi linguaggio di programmazione) che utilizza contemporaneamente codice gestito e codice non gestito. Il gestore di marshalling personalizzato illustrato nel codice che segue utilizza ad esempio il metodo Marshal.ThrowExceptionForHR(int HResult) per generare un'eccezione con uno specifico valore di HRESULT. Il metodo esamina l'HRESULT e genera il tipo di eccezione appropriato. L'HRESULT del frammento di codice riportato di seguito genera ad esempio ArgumentException.

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

Nella tabella che segue viene fornita la mappa completa delle associazioni tra ciascun HRESULT e la classe di eccezione di .NET Framework ad esso paragonabile.

Per recuperare informazioni sull'errore, il client gestito deve esaminare i campi dell'oggetto di eccezione generato. Affinché l'oggetto di eccezione fornisca informazioni utili su un errore, è necessario che l'oggetto COM implementi l'interfaccia IErrorInfo. Il runtime utilizza le informazioni fornite da IErrorInfo per inizializzare l'oggetto di eccezione.

Se l'oggetto COM non supporta IErrorInfo, il runtime inizializzerà un oggetto di eccezione con i valori predefiniti. Nella tabella che segue vengono elencati tutti i campi associati a un oggetto di eccezione e viene identificata l'origine delle informazioni predefinite adottata quando l'oggetto COM supporta IErrorInfo.

Si noti che talvolta un HRESULT può essere ignorato dal runtime quando è presente un'interfaccia IErrorInfo sul thread. Questo comportamento può verificarsi nei casi in cui l'HRESULT e l'interfaccia IErrorInfo non rappresentano lo stesso errore.

I campi di eccezione, quali Message, Source e StackTrace, non sono disponibili per StackOverflowException.

Vedere anche

Altre risorse

Interoperabilità COM avanzata

Gestione e generazione di eccezioni