我必须创建一个 dll 以使旧版客户端能够继续使用 COM 访问中间层。新的中间层使用 WCF/.net 4.5，所以我将通过 COM 公开一个 .net 4.5 dll。
我的问题是如何返回错误/发生错误时返回什么。我发现这方面的信息很少。目前我可以找到的现有客户端中没有错误处理，因此我不能将其用作基准。
我可以只使用标准的 try/catch 方法，抛出一个 .net 错误，然后让客户端解决它，还是在这种情况下我需要做更多的事情来启用错误处理？
最佳答案
不幸的是，这不是一个小细节。 COM 客户端代码查看返回的 HRESULT 并对特定值使用react当然并不少见。可能是错误解决方法，可能是自定义错误报告，可能是“预计会失败，让我们这样做”代码流。这种代码的复杂程度与 COM 组件存在多长时间以及它过去的麻烦程度有很大关系。
但是，是的，很难进行逆向工程。一定要找机会采访客户代码程序员，问问他是做什么的。并查看您的原始代码。无论您之前在哪里返回了特定的 HRESULT，您都希望确保在 .NET 替换中再次执行此操作。使用 Marshal.ThrowExceptionForHR()。
.NET 本身对良好的 COM 错误报告具有出色的支持。您在 [ComVisible] 类方法中抛出的任何异常都会被自动捕获并映射到返回给调用者的 HRESULT。 CLR 实现 IErrorInfo 以便客户端可以获得丰富的错误信息，其中包括错误的文本描述，而不仅仅是 HRESULT。因此 Exception.Message 不必丢失，假设客户端使用该接口(interface)。
在 COM 允许的范围内，每个标准 .NET 异常派生对象都映射到具有逻辑映射的特定 HRESULT。就像 OutOfMemoryException 映射到 E_OUTOFMEMORY，ArgumentException 映射到 ERROR_INVALID_PARAMETER，IOException 映射到原始 winapi 错误代码等等。即使客户端代码只显示或记录 HRESULT，仍然有办法将其映射回原始 .NET 异常。
但当然，如果没有神圣堆栈跟踪，请考虑记录它。编写该 try/catch/throw 代码非常痛苦，但在芯片故障时绝对是无价的。他们会倒下的。
关于.net - 处理 COM 中的 .net 错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20229837/