The common language runtime transforms well-known HRESULTs to.NET exceptions, enabling COM objects to return meaningful error information to managed clients. The HRESULT to exception mapping also works in the other direction by returning specific HRESULTs to unmanaged clients. For mapping details, see [<topic://cpconhresultsexceptions>].

When the runtime encounters an unfamiliar HRESULT (an HRESULT that lacks a specific, corresponding exception), it throws an instance of the System.Runtime.InteropServices.COMException class. This all-purpose exception exposes the same members as any exception, and includes a public ErrorCode property that contains the HRESULT returned by the callee. If an error message is available to the runtime (obtained from the IErrorInfo interface or the Err object in Visual Basic, or in some cases from the operating system), the message is returned to the caller. However, if the COM component developer fails to include an error message, the runtime returns the eight-digit HRESULT in place of a message string. Having an HRESULT allows the caller to determine the cause of the generic exception.

Although you can use the System.Runtime.InteropServices.COMException class to return specific HRESULTs to unmanaged clients, throwing a specific.NET exception is better than using a generic exception. Consider that managed clients as well as unmanaged clients can use your.NET object, and throwing an HRESULT to a managed caller is less comprehendible than throwing an exception.

Namespace: System.Runtime.InteropServices
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 1.0.5000.0, 2.0.0.0, 4.0.0.0