Sign in to follow this  
MTclip

Error checking ?? reasonable""??

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 this post


Link to post
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 _DEBUG
if(FAILED(hr)){
// CODE
}
#endif

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this