我必須創建一個dll以使舊版客戶端能夠繼續使用COM訪問中間層。新的中間層使用WCF/.net 4.5，所以我將通過COM公開.net 4.5 dll。在COM中處理.net錯誤
我的問題是如何返回錯誤/發生錯誤時返回的內容。我發現有關這方面的信息很少。目前我無法找到現有客戶端的錯誤處理功能，因此我無法將其作爲基準。
我可以只使用標準的try/catch方法，拋出.net錯誤，並讓客戶端將其排除，或者我還需要做更多的事情來啓用這種情況下的錯誤處理？
不幸的是，這不是一個小細節。 COM客戶端代碼查看返回的HRESULT並對特定值做出反應當然並不少見。可能是一個錯誤解決方法，可以自定義錯誤報告，可能是「預計失敗，讓我們這樣做」代碼流。這種代碼的複雜程度與COM組件到底有多長時間以及過去有多麻煩有很大關係。
但是，很難進行反向工程。儘量找機會採訪一位客戶端代碼程序員，只問他做了什麼。並審查您的原始代碼。無論您在哪裏返回特定的HRESULT，都希望確保您在.NET更換中再次執行此操作。使用Marshal.ThrowExceptionForHR（）。如果你使用的是.NET錯誤報告，那麼.NET本身就有很好的支持。您在[ComVisible]類方法中拋出的任何異常都會自動捕獲並映射到返回給調用者的HRESULT。 CLR實現了IErrorInfo，因此客戶端可以獲得豐富的錯誤信息，其中包括除了HRESULT之外的錯誤的文本描述。因此，假設客戶端使用該接口，Exception.Message不必迷路。
只要COM允許，每個標準.NET異常派生對象都映射到具有邏輯映射的特定HRESULT。像OutOfMemoryException映射到E_OUTOFMEMORY，ArgumentException映射到ERROR_INVALID_PARAMETER，IOException映射到原始的winapi錯誤代碼等。即使客戶端代碼只顯示或記錄HRESULT，仍然有辦法將其映射回原始的.NET異常。
但是沒有Holy Stack跟蹤當然，請考慮日誌記錄。寫這個try/catch/throw代碼非常痛苦，但在芯片關閉時絕對是無價的。他們會失望。