<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: On Error Checking</title>
	<link>http://www.sethgorden.com/index.php/archives/138</link>
	<description>Game Development Conversations</description>
	<pubDate>Mon, 06 Feb 2012 01:58:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: Seth Gorden</title>
		<link>http://www.sethgorden.com/index.php/archives/138#comment-576</link>
		<dc:creator>Seth Gorden</dc:creator>
		<pubDate>Mon, 19 Jul 2010 20:19:23 +0000</pubDate>
		<guid>http://www.sethgorden.com/index.php/archives/138#comment-576</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>That is definitely a good point to consider non-programmer testers. Most of the places where I&#8217;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 &#8220;commit changes&#8221; 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&#8217;t want one of those slip through the cracks and cause false crashes for designers or other QA folks! Thanks for the feedback, Aaron.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aaron Melcher</title>
		<link>http://www.sethgorden.com/index.php/archives/138#comment-567</link>
		<dc:creator>Aaron Melcher</dc:creator>
		<pubDate>Sat, 17 Jul 2010 15:24:54 +0000</pubDate>
		<guid>http://www.sethgorden.com/index.php/archives/138#comment-567</guid>
		<description>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</description>
		<content:encoded><![CDATA[<p>Not a huge fan of asserts unless its to raise a flag that the game/system has become unstable.  Unstable to me doesn&#8217;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&#8217;s score being out of bounds or something silly.  Thats just not cost effective.</p>
<p>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.</p>
<p>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 &#8220;crashed&#8221; when it was an assert is useless and just wastes everyone&#8217;s time.  </p>
<p>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.</p>
<p>Aaron</p>
]]></content:encoded>
	</item>
</channel>
</rss>

