次の方法で共有

FACILITY_ITFのコード

  • [アーティクル]

FACILITY_NULLやFACILITY_RPCなどのファシリティのあるHRESULTは、単一のソースである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でのエラー処理