Clever Geek Handbook

.Net custom exception handling in COM + (VB)?

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

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

  • which can occur if the precondition is not met (for example, the start date given as a parameter is less than 3 months after the delivery end date as a parameter, I might want to run StartDateNotValidException)
  • exceptions that can happen as part of a webservice call (timeout, 404, etc.).

I would like to return some specific feedback to the user and / or write some information to the log if one of these events occurs. I was thinking about returning Int return codes from .Net code and throwing exceptions, but it is possible that the calling VB code could eventually be ported to .Net, so I would like to use Exceptions if possible.

I read on MSDN that COM Interop automatically converts standard library exceptions to HRESULT; does anyone have any experience using this? Can this be used to translate custom .NET exceptions into error conditions that I can handle in VB?

Thanks Nick

+1


source to share


2 answers


I'm sure I've seen this before, but it was in my previous job so I can't verify 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 pretty good because you can use HResult in unmanaged code and also handle the typed exception correctly in the managed client.



Please let me know if this actually works.

+1


source


I ended up using the following method:

  • there is a large dictionary that maps our application VB error codes to our application specific C # Exceptions
  • write a method that converts C # exceptions to VB error codes (and vice versa)
  • returns an array of strings from methods containing any business exceptions that occurred in the method call (currently only two)


The reason for this is that it would be too cumbersome to adapt our exception tree to extend COMException (more cumbersome than above anyway). So, I've never tried inheriting from COMException and checked if ErrorCode is correctly converted to HResult.

Thanks for the offer, although I apologize for not trying it.

0


source






More articles:


All Articles