次の方法で共有

FACILITY_ITFのコード

  • [アーティクル]

HRESULT、FACILITY_NULLやFACILITY_RPCなどの機能は、単一のソース (Microsoft) で定義されているため、普遍的な意味を持ちます。 ただし、FACILITY_ITFの HRESULT は、返される関数またはインターフェイス メソッドによって決定されます。 つまり、2 つの異なるインターフェイス メソッドから返される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は、ほとんどの開発者が汎用的に有効にしたい特定のエラー コードです。

COM でのエラー処理の