Lets talk about assert

Gather around children, uncle Roach has something to teach you all.

The assert code path should be defined in non-assert code
Can someone tell me what's WRONG with the following chunk of code?

int customVector::getValueAtIndex(int idx)
{
   assert(idx > 0 && idx < mNumElements);
   return mValues[idx];
}

"Why no uncle Roach, that sure looks fine to me!"

Well it's not; Can you tell me what happens when that assert gets compiled out in a final build, and the index value is out of range? That's right children; Problems happen.


Firstly, we need to understand that an assert is a great debugging tool, because of it's usage and ability to alert the programmer to specific boundary cases of our coding patterns. Checking that a value is null is a great example:

void deleteThis(object* obj)
{
   assert(obj != NULL);
   customDelete(obj);//** edited.. see comment below
}

The real question here though, is what SHOULD the code do in the case that the assert doesn't exist? If you take that into account, than this is not a safe snippet of code; and definitely not something you'd like to ship in your $20million dollar project.The issue is that the code path to be handled when the assert is compiled out is missing; which is crucial, as you'll get a random crash in final builds, that is damn difficult to rack down if you don't properly check for this condition. Below is the proper snippet :

void deleteThis(object* obj)
{
   assert(obj != NULL);
   if(obj == NULL) return;
   customDelete(obj); //**edited.. See comment below
}

The rule of thumb here is that you should properly define the accurate code path to occur when asserts are removed.


Don't use an assert when you meant to use fail
Assert != fail. Let me just get that out in the open. When you want an ASSERT, you're generally looking for information about a specific conditional that can allow your application to hault operation in order to present some information to the user, before deciding if it would like to stop execution (fatal assert), continue on, or ignore that assert in the future.

When you want a FAIL though, you are looking that the code is in a state that things are generally wonky and recovery will be an issue. You'd generally like all the logging information and what-not that an assert has, but a fail is generally more of a hard-termination.

"Well golly uncle Roach, a fail sounds like a fatal assert to me. Why can't I just use assert and stop execution?"

Excellent question Cleetus. The problem is that as a programmer, you should be using the proper syntax for the proper result. Throwing assert as a catchall seems like a good idea, but quite frankly, there's positions where you WANT a failure to occur, so that you can accurately catch it.

A great example is loading data from disk :

void loadAssetArchiveFromDisk(const char* archiveName)
{
   const retCode = loadArchive(archiveName);
   assert(retCode == LOAD_OK); //Dirty disk error?
   if(retCode == LOAD_OK)
      OpenAndProcessArchive(archiveName);
}

Let's say the above code fails to load the archive. The assert fires, and we have the option to continue forward. But is that really what we want to occur? Let's say that this is a critical archive that contains all the strings for the entire game. Would we really want to gracefully bail out like this with a simple assert?

void loadAssetArchiveFromDisk(const char* archiveName, bool failOnNotLoad)
{
   const retCode = loadArchive(archiveName);
   if( failOnNotLoad && retCode != LOAD_OK)
      Fail("retCode != LOAD_OK");// NON RECOVERABLE

      OpenAndProcessArchive(archiveName);
}

Now the code will properly fail if the archive doesn't load (and it's a core archive). This allows you to properly call dirtyDiskError on the console, or whatever other handling you want. But not ASSERT!

So what?
The point here is that assert is a good idea, but it's sometimes used as a catch-all drunk drawer by programmers when it should really be used in proper places at proper times. It is not a silver bullet of debugging, but most programmers use it like it is.

Be careful though, because silver bullets can still shoot you in the foot.

~Main

** changed Originally from "delete obj" to "customDelete(obj)" in order to continue to provide my point without everyone getting caught up with the fact that "delete NULL" is valid in C++. Thank you for your feedback.