Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Spider_In_A_Web

Generic HRESULT

This topic is 6067 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
S_OK = ok
E_FAIL = failure

You might want to check in MSDN for the HRESULT breakdown. It''s really a 32bit value comprised of 4 fields: Severity code, context field, facility field, and an error code. The breakup is as such:

bit
31 : SCODE
20-30 : CONTEXT
16-19 : FACILITY
0-15 : CODE

From MSDN:

"
The high-order bit in the HRESULT or SCODE indicates whether the return value represents success or failure. If set to 0, SEVERITY_SUCCESS, the value indicates success. If set to 1, SEVERITY_ERROR, it indicates failure.

The context field is reserved in the SCODE on 16-bit platforms and does not exist in the version for 32-bit platforms. The R, C, N, and r bits are also reserved.

The facility field in both versions indicates the system service responsible for the error. Microsoft allocates new facility codes as they become necessary. Most SCODEs and HRESULTs set the facility field to FACILITY_ITF, indicating an interface method error.

The code field is a unique number that is assigned to represent the error or warning.

By convention, HRESULTs generally have names in the following format:

Facility_Severity_Reason

Facility is either the facility name or some other distinguishing identifier; Severity is a single letter, S or E, that indicates whether the function call succeeded (S) or produced an error (E); and Reason is an identifier that describes the meaning of the code. For example, the status code STG_E_FILENOTFOUND indicates a storage-related error has occurred; specifically, a requested file does not exist. Status codes from FACILITY_NULL omit the Facility_ prefix.

Error codes are defined within the context of an interface implementation. Once defined, success codes cannot be changed or new success codes added. However, new failure codes can be written. Microsoft reserves the right to define new failure codes (but not success codes) for the interfaces described in FACILITY_ITF or in new facilities.
"

Share this post


Link to post
Share on other sites
Although the return value for "OK" is (or should be) always 0, you should still test with the macros SUCCEEDED() and FAILED() instead of testing against return values to be absolutely sure.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!