| 1001010.com |
one zero zero one zero one zero dot com |
Personal gripe: asserts are NOT a complete solution for error checking.
Sometimes I have to fight the urge to fix code like this.
void SomeFunction(int * pnReturnValue)
{
//Check Param
assert(pnReturnValue);
//Set the return value
*pnReturnValue = 5;
}
See the multiple problems?
1. assert only works in debug builds (obvious)
2. It is delusional to believe that you will cover all code paths in your debugger so that you can "fix all calling functions to call your function correctly". Here's some news for you buddy - 6months from now someone will call your function incorrectly. And that someone may or may not be you.
3. end users may get a dereferenced null pointer exception (0x00000005) and give your CS team hell.
4. Fellow programmers working on the same project will taunt you in a public forum! But that's OK - I used to make the same mistake early in my programming carrer, that is until someone pointed out this mistake.
Here's how I would rewrite it.....
void SomeFunction(int * pnReturnValue)
{
//Check Param
if( ! pnReturnValue )
{
assert(!"ERROR: SomeFunction - bad param - null pointer");
return;
}
//Set the return value
*pnReturnValue = 5;
}
Notice how I changed around the assert & created code that would always be built? The assert isn't evil, I still included it - but I changed it to a custom error string that will appear in my debugger as a hint as to what went wrong.
Happy Coding!