FACILITY_ITF中的程序代碼
具有FACILITY_NULL和FACILITY_RPC等設施的 HRESULT具有通用意義，因為它們定義於單一來源：Microsoft。 不過， FACILITY_ITF中的 HRESULT是由傳回它們的函式或介面方法所決定。 這表示從兩個不同的介面方法傳回FACILITY_ITF中相同的32位值可能有不同的意義。
FACILITY_ITF中的 HRESULT 在不同的介面中可能有不同的意義，在於 HRESULT會保留為 32 位的有效數據類型大小。 不幸的是，32 位不足以開發錯誤碼配置系統，以避免在不同位置的不同時間由不同程式設計人員配置的衝突程序代碼（與處理介面標識符和 CLSID 不同）。 因此，32 位 HRESULT 的結構可讓 Microsoft 定義數個通用錯誤碼，同時允許其他程式設計人員定義新的錯誤碼，而不必擔心衝突。 狀態代碼慣例如下所示：
- FACILITY_ITF以外的設施狀態代碼只能由 Microsoft 定義。
- 設備中的狀態代碼FACILITY_ITF是由傳回狀態代碼之介面或函式的開發人員所定義。 為了避免發生衝突的錯誤碼，無論誰定義介面負責協調和發佈與該介面相關聯的FACILITY_ITF狀態代碼。
所有 COM 定義的FACILITY_ITF程式代碼都有0x0000 0x01FF範圍內的程式代碼值。 雖然在 FACILITY_ITF 中使用任何程式代碼是合法的，但建議只使用0x0200 0xFFFF範圍內的程式代碼值。 這項建議是減少任何 COM 定義錯誤混淆的方法。
此外，也建議開發人員定義新的函式和介面，以傳回 COM 所定義的錯誤碼，以及FACILITY_ITF以外的設施。 特別是，未來任何有機會使用 RPC 的介面，都應該將FACILITY_RPC程式代碼定義為合法的。 E_UNEXPECTED是大部分開發人員想要讓通用合法化的特定錯誤碼。
相關主題