通过

FACILITY_ITF中的代码

  • 项目

具有FACILITY_NULL和FACILITY_RPC等设施的 HRESULT具有通用意义，因为它们在单个源中定义：Microsoft。 但是，FACILITY_ITF中的 HRESULT由返回它们的函数或接口方法决定。 这意味着，从两个不同的接口方法返回FACILITY_ITF中相同的 32 位值可能有不同的含义。

HRESULT在不同接口 FACILITY_ITF中可能有不同的含义的原因是，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 中的 错误处理