Game Development Conversations
On Error Checking
My new favorite coding trick is as follows:
#ifdef _DEBUG
assert( something );
#endif
In terms of error-checking, there are couple interesting things about this code. Firstly, as can be seen, this code is only compiled in Debug mode. This results in faster performing code in Release mode, since we’re removing some of it. But the more curious part is that there are no error conditions here to trap, really.
When in debug mode, the program execution stops here, and forces you to address the problem such that it does not occur. There are many practices about how to capture and handle error conditions when they happen, but rarely do I read about how to write (or at least encourage) error-free code.
Error checking is great, but here I submit that not causing errors is greater. Error-free code may be a tall order, and certainly there are many situations that call for robust error handling. But this is one way I’ve found to encourage discipline in the way I control general program execution. And it works reliably for functions of limited scope, like class accessors and modifiers.
Also, I should note that I tend to use these on functions that are performance critical, rather than those which only get called when an object is created or destroyed. Initialization code, if only called once, doesn’t need to optimized the same way. So for those, I choose to return codes and track or respond to error conditions as needed.
Do you have any favorite code snippets or things you do make your life easier? Have any feedback on the _DEBUG example here? Leave a comment and let me know!
July 17th, 2010 at 9:24 am
Not a huge fan of asserts unless its to raise a flag that the game/system has become unstable. Unstable to me doesn’t mean some game logic went wonky, or a texture failed to load. Those are undesirable, but should not halt the program so the developer has to stop whatever it is they were doing to fix some random issue with the player’s score being out of bounds or something silly. Thats just not cost effective.
On the other hand if memory is getting trashed, rendering went down or we were about to crash anyway asserts should be used. They should also be pared with a detailed comment or message to the log about what went wrong.
When the game gets more into the hands of testing and other non game departments less asserts should be used. More visible things like warning and error pop ups should alert the player to inform programming of the error that occurred. Getting a designer or someone telling you the game “crashed” when it was an assert is useless and just wastes everyone’s time.
Also just as a personal preference I would wrap up the debug stubbing in a macro (like DEBUG_ASSERT(condition, message) or something) so my fingers will be more happy :-D. Hahahaha, longest comment ever sry.
Aaron
July 19th, 2010 at 2:19 pm
That is definitely a good point to consider non-programmer testers. Most of the places where I’ve been asserting have to do with bounds checking on arrays or other circumstances that lead to heap corruption, or similar (which can lead to serious crashes). In this case, before I “commit changes” or make code available to any other people, it would have to be verified as never causing those assert conditions. Though, I could see that being a potentially problematic policy to maintain in a larger company or team. Definitely don’t want one of those slip through the cracks and cause false crashes for designers or other QA folks! Thanks for the feedback, Aaron.