在COM +（VB）中处理自定义.Net异常？

Question

I'm about to start writing a .Net component which will be called from a VB COM+ service (the new component is a DLL which calls out to a webservice and returns based on the response). I'm not sure how to handle error conditions that might occur in the .Net code in the calling VB.

The two types of errors I'm worried about are:

• exceptions that I might like to throw if a precondition is not met (eg the start date supplied as a parameter is less than 3 months after the end date supplied as a parameter; I might want to throw a StartDateNotValidException)
• exceptions that are likely to happen as part of the webservice call (time out, 404 etc).

I'd like to return some specific feedback to the user and/or log some information to a log if either of these occur. I'd thought about returning Int return codes from the .Net code and avoiding Exceptions, but it's possible that the calling VB code may eventually be migrated to .Net, so I'd like to use Exceptions if possible.

I read on MSDN that COM Interop will automatically convert standard library exceptions to HRESULTs; has anyone had any experience using this? Could this be used to translate custom .Net exceptions to error conditions that I can handle in VB?

Thanks, Nick

Answer 1

I am sure I have seen it done before, but it was in my previous job so I can't check the details. I think we inherited our exception classes from COMException and set the correct ErrorCode (which should be translated as HResult in unmanaged code). This is quite nice, because you can use HResult in unmanaged code as well as properly handle typed exception in managed client.

Please let me know if it actually works.

Answer 2

I ended up using the following method:

• have a big Dictionary that maps our application-specific VB error codes to our application-specific C# custom exceptions
• write a method that converts C# exceptions to VB error codes (and vice-versa)
• return an array of strings from the methods containing any business exceptions that occurred in the method call (there are only currently two of these)

The reason for doing this is that it was going to be too cumbersome to adapt our exception tree to extend COMException (more cumbersome than the above anyways). So, I never tried out inheriting from COMException and checking whether the ErrorCode got correctly converted to an HResult.

Thanks for the suggestion though, and apologies for not trying it out.