locked
VB.NET COM error handling

    Question

  • When my old VB6 app got a com error, VB6 reported the error including the extra info from the COM server's ErrorInfo interface.

    I've upgraded the app to VB.NET. Now all I get is "Error HRESULT E_FAIL has been returned from a call to a COM component." - this is whether I use the old OnError method or the new:
     Try
    ...
    Catch e As System.Runtime.InteropServices.COMException
    ...
    End Try

    As far as I can tell e.Message should have the ErrorInfo message it not the generic message above.

    What am I missing?

    Thanks In Advance,
    Simon
    Thursday, January 31, 2008 9:56 AM

Answers

  • Simon Heffer,

     

    Based on your post, you mentioned "I've upgraded the app to VB6", however, I guess you mean upgrade the app to VB.NET because of your title and the description follows up.

     

    A COMException exception is thrown when an unrecognized HRESULT is returned from a COM method call. The common language runtime (CLR) 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.

     

    In this situation, you can either check the ErrorCode property of the exception to determine the HRESULT returned by the COM object or disable the hosting process. For further information, please take a look at the article Troubleshooting Exceptions: System.Runtime.InteropServices.COMException

     

    COM methods report errors by returning HRESULTs; .NET methods report them by throwing exceptions. The runtime handles the transition between the two. Each exception class in the .NET Framework maps to an HRESULT. Please read the information in MSDN on HRESULTs and Exceptions

     

    In addition, I would like to provide you the following article that can help you further:

     

    Get Seamless .NET Exception Logging From COM Clients Without Modifying Your Code

     

    Throwing Custom Exception Types from a Managed COM+ Server Application


    Hope that can help you.

    Sunday, February 03, 2008 6:08 AM

All replies

  • Simon Heffer,

     

    Based on your post, you mentioned "I've upgraded the app to VB6", however, I guess you mean upgrade the app to VB.NET because of your title and the description follows up.

     

    A COMException exception is thrown when an unrecognized HRESULT is returned from a COM method call. The common language runtime (CLR) 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.

     

    In this situation, you can either check the ErrorCode property of the exception to determine the HRESULT returned by the COM object or disable the hosting process. For further information, please take a look at the article Troubleshooting Exceptions: System.Runtime.InteropServices.COMException

     

    COM methods report errors by returning HRESULTs; .NET methods report them by throwing exceptions. The runtime handles the transition between the two. Each exception class in the .NET Framework maps to an HRESULT. Please read the information in MSDN on HRESULTs and Exceptions

     

    In addition, I would like to provide you the following article that can help you further:

     

    Get Seamless .NET Exception Logging From COM Clients Without Modifying Your Code

     

    Throwing Custom Exception Types from a Managed COM+ Server Application


    Hope that can help you.

    Sunday, February 03, 2008 6:08 AM
  • Hi Bruno,

    Thanks for that information. I had read some of that info , I'll go through the rest and see if it addresses my problem. (yes it was a typo - I had upgraded top VB.NET)

    Particularly I had expected that the error description my COM server supplies through the ErrorInfo interface would be available in the e.Message (or perhaps the InnerException but that's not filled in) rather than the generic info I described receiving in my first post.

    Not surprisingly I get the same issue using a C# client.

    Cheers,
    Simon
    Monday, February 04, 2008 9:02 AM