FailFast in non-HRESULT returning COM impl methods

[AArnott]

Confirming here so we are on the same page, the implementation of the COM interface is in managed code, right? We are talking about CCWs.

So... you'd rather see the process exit immediately when an exception is thrown from managed code in a COM method that doesn't return HRESULT?

Yes, I would prefer the fail fast on the managed side to throwing a managed exception and having it propagate. Coming back into unmanaged (i.e., native) code means we are assuming the caller is going to have set up a SEH handler. In my experience this is exceedingly rare and results in DMPs that aren't always that easy to root cause and if it was detected I'm not sure what the caller expects to do with that exception. It also assumes the transition from managed to SEH is something the caller thought about - also unlikely.

COM interfaces that don't return an HRESULT indicate they don't expect a recoverable error in any form, that is how I've always interpreted them. The ITypeInfo members that return void, such as ReleaseVarDesc(), indicate to me that the callee isn't expecting or designed to handle invalid input. One could debate whether NULL is valid or not, but it is taking an arbitrary pointer to release and giving a invalid pointer is expensive to detect and unlikely to have a lot of utility, so fail fast. Alternatively the callee could defer to the dependent memory allocator, which is typically "fail fast" also.

If we are looking to support COM, actual COM not any of the various "subsets", then a member either returns an HRESULT, doesn't expect to have invalid input or swallows all failures and nicely returns. Letting exceptions propagate out from a COM member isn't supported and isn't something the .NET Interop team is going to recommend going forward.

/cc @jkoritzinsky @elinor-fung

Originally posted by @AaronRobinsonMSFT in #825 (comment)

[jkoritzinsky]

If we decide that the "swallow" route is the route we want to go instead of FailFast (though I think FailFast is better as it makes it easier to determine where the failure occured), it might make sense to call SetErrorInfo with a CCW for the exception object. That way the error is still discoverable through the COM model.