# Error checking ?? reasonable""??

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

## Recommended Posts

what is a reasonable amount of error checking... for instance... the D3DXSPRITE it returns an HRESULT after the draw().. if you were to call it 500 times in a frame is it reasonable to error check that call ... that is just one example... should you check every thing??

##### Share on other sites
Depending on how much error checking you'll hardly notice, or not even notice a difference at all in preformance. If you're really worried about error checking being a massive problem then you could always have your code exclude the error checking code when you do a release build.

If I remember correctly (I haven't really used it much).

HRESULT hr = D3DBLAHXOMG(&device, ...);#if _DEBUGif(FAILED(hr)){ // CODE}#endif

##### Share on other sites
A reasonable amount of error checking would be to check everything that could fail. An error check is a simple comparison, so it shouldn't impair your performance.

##### Share on other sites
You should check **everything** for the debug build, as that's the purpose of it. For a release build, you can probably get away with only checking for critical errors...

In order to achieve this, you can use some funky pre-processor trickery similar to what PumpkinPieman suggested.

The following example is taken from the SDK sample code, if you notice they use a lot of V_RETURN( ) and V( ) wrappers around function calls that return an HRESULT value:

//This one should fail the function if the single call fails:V_RETURN( pd3dDevice->CreateVertexDeclaration( decl, &g_pVertexDeclaration ) );//This one isn't so fatal, but report it anyway:V( D3DXComputeNormals( pTempMesh, NULL ) );

If you look up those two macros in the D3D header file dxstdafx.h you'll see:
#if defined(DEBUG) | defined(_DEBUG)    #ifndef V        #define V(x)           { hr = x; if( FAILED(hr) ) { DXUTTrace( __FILE__, (DWORD)__LINE__, hr, L#x, true ); } }    #endif    #ifndef V_RETURN        #define V_RETURN(x)    { hr = x; if( FAILED(hr) ) { return DXUTTrace( __FILE__, (DWORD)__LINE__, hr, L#x, true ); } }    #endif#else    #ifndef V        #define V(x)           { hr = x; }    #endif    #ifndef V_RETURN        #define V_RETURN(x)    { hr = x; if( FAILED(hr) ) { return hr; } }    #endif#endif

The important thing I'm trying to point out is that the macros have two definitions - depending on whether the DEBUG or _DEBUG flags are defined (check your compiler profile settings and you'll see them in the right places).

I don't personally use the above macros for my production code, but I do have something similar.

The advantage of doing it this way is that you ALWAYS type your code the same way (e.g. enclose calls in V_RETURN()) but at compile time they can resolve to either heavy duty debug tracing OR for release builds they (pretty much) do nothing...

Some of the guru's say that the C-Preprocessor is an evil feature, and in places it is, but tricks like this are sooo useful [grin]

hth
Jack

1. 1
2. 2
3. 3
Rutin
22
4. 4
frob
16
5. 5

• 9
• 33
• 13
• 13
• 10
• ### Forum Statistics

• Total Topics
632579
• Total Posts
3007183

×