Procedura: Eseguire il mapping di HRESULT ed eccezioni

I metodi COM segnalano gli errori restituendo HRESULT; .NET metodi li segnalano generando eccezioni. Il runtime gestisce la transizione tra i due. Ogni classe di eccezione in .NET esegue il mapping a un HRESULT.

Le classi di eccezioni definite dall'utente possono specificare qualsiasi HRESULT appropriato. Queste classi di eccezioni possono modificare dinamicamente il valore HRESULT in modo che venga restituito quando l'eccezione viene generata impostando il HResult campo sull'oggetto eccezione. Informazioni aggiuntive sull'eccezione vengono fornite al client tramite l'interfaccia IErrorInfo , implementata nell'oggetto .NET nel processo non gestito.

Se si crea una classe che estende System.Exception, è necessario impostare il campo HRESULT durante la costruzione. In caso contrario, la classe base assegna il valore HRESULT. È possibile eseguire il mapping di nuove classi di eccezioni a un HRESULT esistente specificando il valore nel costruttore dell'eccezione.

Si noti che il runtime a volte ignora un HRESULT nei casi in cui è presente un IErrorInfo sul thread. Questo comportamento può verificarsi nei casi in cui HRESULT e non IErrorInfo rappresentano lo stesso errore.

Per creare una nuova classe di eccezione ed eseguirne il mapping a un HRESULT

1. Usare il codice seguente per creare una nuova classe di eccezione denominata NoAccessException ed eseguirne il mapping a HRESULT E_ACCESSDENIED.

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

È possibile che si verifichi un programma (in qualsiasi linguaggio di programmazione) che usa codice gestito e non gestito contemporaneamente. Ad esempio, il marshaller personalizzato nell'esempio di codice seguente usa il Marshal.ThrowExceptionForHR(int HResult) metodo per generare un'eccezione con un valore HRESULT specifico. Il metodo cerca HRESULT e genera il tipo di eccezione appropriato. Ad esempio, HRESULT nel frammento di codice seguente genera ArgumentException.

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

La tabella seguente fornisce i mapping comuni di HRESULT alla relativa classe di eccezione paragonabile in .NET. I valori HRESULT senza mapping espliciti vengono mappati a COMException. La mappatura completa e aggiornata è disponibile nel repository dotnet/runtime.

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

Se l'oggetto COM non supporta IErrorInfo, il runtime inizializza un oggetto eccezione con valori predefiniti. La tabella seguente elenca ogni campo associato a un oggetto eccezione e identifica l'origine delle informazioni predefinite quando l'oggetto COM supporta IErrorInfo.

Si noti che il runtime a volte ignorerà un HRESULT nei casi in cui è presente un IErrorInfo sul thread. Questo comportamento può verificarsi nei casi in cui HRESULT e non IErrorInfo rappresentano lo stesso errore.

I campi eccezione, ad esempio Message, Sourcee StackTrace non sono disponibili per .StackOverflowException

Vedere anche

• Interoperabilità COM avanzata
• Exceptions