Checking for errors is a good programming habit, but new programmers haven’t yet learned this habit. Most of the methods and functions you can call in Direct3D return an
HRESULT, or a COM “handle to a result”, that indicates success or failure. Most of the time, your expectation is that these calls should succeed. This leads people to write “happy path” code that assumes that the call will succeed instead of verifying that it succeeded.
SUCCEEDED macros to turn an
HRESULT into a boolean value that can be used in a conditional statement to determine the success or failure of any given
HRESULT. Its not a good idea to compare the return value to specific failure codes because those failure codes may change and then your comparison logic will be wrong. The macros above tell you the general status of an
HRESULT: success or failure.
Just as there are multiple failure codes that can be encoded in an
HRESULT, there are also multiple success values. Comparing the result code to
S_OK can fail for the same reasons that comparing the result code to a specific failure code can fail.
When programming in Direct3D, small errors early in the use of the device tend to manifest themselves as an incorrect rendering that’s only noticed much later after the source of the problem. If you check all your
HRESULT values diligently, then you will be notified at the source of the problem and not later when the incorrect rendering is presented to the screen.
A failure to check the result codes of methods and functions is a common problem among beginning Direct3D programmers. It distracts them from the true source of the error. Checking the result codes diligently will keep you focused on the error when it occurs instead of having to backtrack in the debugger.