Re: COM sometimes turns exceptions into HRESULTs, sometimes doesn't - why?

Tech-Archive recommends: Fix windows errors by optimizing your registry

Hi Kim,

Thanks for the comments. Inline:

Kim Gräsman wrote:
It seems that the 'other object' is probably running in another apartment, and you're talking to a proxy. The proxy/stub pair must try and handle exceptions, so as not to tear down the mechanisms for marshalling, which may run on a secondary thread. That's probably why they translate exceptions into HRESULTs.

Well, yes. That seems like what must be happening. But I can't see why one is different.

In pseudo code, both do this

threadproc
 try
   create object
   call object.method
      cause an access violation
 catch
    log error

In one case the error can be caught, in the other case it can't.
There must be some difference in the objects, but they both look the same in COM terms (ATL, multithreaded).

Re C++ exceptions
Nope, that's likely a bad idea, as you noticed. There's not only a language boundary, but a run-time boundary as well. If your COM object is constrained to be used from C++, and only from the same thread (strictly speaking, apartment) in the same process, I wonder why you went to the trouble of making it a COM object in the first place.

Well that's a good question ... basically there are multiple DLLs implementing a common interface, loaded at runtime depending on configuration. It could have done with exported C++ classes as well, I guess (or even a C API). Someone got carried away with COM.

.

Relevant Pages