Why is HRESULT 0 for success?

Question

I just ran into something very inconvenient when dealing with HRESULT return values, it seems that success is 0 and failure is 1. What is the logic behind this?

I really tried if(!hr) and failed, wasting an hour of my life until I realized that the actual success of retval is 0. I would like to call the person who thought about this an idiot, but I will try to cool down - hoping that who something will shed light on this agreement.

Answer 1

The initial goal of HRESULT was to formally set error code ranges for Microsoft's general and internal use, to prevent collisions between error codes in different subsystems of the OS / 2 operating system.

Therefore, a value of 0 (the highest bit of HRESULT) means “no error”, that is, success.

But you need to be careful, because for HRESULT it is possible that the most significant bit is set to 0, and the other bits are different from 0. This means that checking if(0 == hr) { ... } may not work for some successful cases. The correct way to check success is if(0 <= hr) { ... } .

Wikipedia more information .

SUCCEEDED and FAILED macros can be used to avoid errors when working with HRESULT values. if(0 <= hr) { ... } and if(SUCCEEDED(hr)) { ... } are basically the same thing.

Answer 2

You are mistaken again, since all system errors in almost all systems return 0, and successful and nonzero return values ​​indicate an error code, using this technique, we can report a different error with only one return value. But for HRESULT we have >= 0 for success and <0 for error, so the value 1 from the HRESULT view is successful not an error. in HRESULT > 0 indicate a warning or information about the function, 0 means absolute success, and <0 indicates an error. HRESULT Layout:

  3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+---------------------+-------------------------------+ |S|R|C|N|r| Facility | Code | +-+-+-+-+-+---------------------+-------------------------------+ where S - Severity - indicates success/fail 0 - Success 1 - Fail (COERROR) R - reserved portion of the facility code, corresponds to NT second severity bit. C - reserved portion of the facility code, corresponds to NT C field. N - reserved portion of the facility code. Used to indicate a mapped NT status value. r - reserved portion of the facility code. Reserved for internal use. Used to indicate HRESULT values that are not status values, but are instead message ids for display strings. Facility - is the facility code Code - is the facility status code 

As you can see, this is one of the best projects with very reasonable support for custom error codes, warnings and information.

Answer 3

Normally, you should use the SUCCEEDED and FAILED macros to test HRESULT , because although the vast majority of functions return S_OK (value = 0) for success, there are equal nonzero success values ​​(e.g. S_FALSE ). Often you will need to check for such values ​​explicitly in cases where they can be returned, but in general, using SUCCEEDED more clear and safe.

 if (SUCCEEDED(hr)) { // ...