Twitter  Facebook  YouTube  E-Mail  RSS
The One Man MMO Project
The story of a lone developer's quest to build an online world :: MMO programming, design, and industry commentary
Crash Early, Crash Hard
By Robert Basler on 2010-12-05 11:01:43
Homepage: www.onemanmmo.com email:one at onemanmmo dot com

When I went through school, I was taught that computer programs should recover gracefully from every possible error condition. That every function return should be checked, and that only through diligent use of nested error handling would reliable programs be built. As a result, the programs I have written have been largely error handling code, and not so much actual "do stuff" code.

I'm here to tell you, this is a complete waste of effort.

It is much better to crash on a bug. Hard. Nothing motivates people to fix problems like someone standing over their desk glaring at them about lost work. And having a program limp along, running error code that has likely never been tested, producing incorrect results -- is a nightmare.

This is particularly a problem with old code. Some of the code I'm using I wrote 19 years ago. I really don't have a clue how it works anymore. If I feed it bad data, I want it to complain, in a very specific fashion, so I can know what the problem is and where to fix it with the least effort.

Now you can't totally get away from error handling. Your program is going to need to be able to deal with malformed inputs, whether from the user, disk or network. But once that's done, you should be done.

The best tool in your debugging arsenal for this is assert. The assert macro allows you to say "I believe that at this point in the program, this is true." I use it most for checking preconditions in functions:

void Singleton::CreatePlane( int wings ) 
{
ASSERT( mPlaneInfo == NULL );
ASSERT( wings == 2 || wings == 4 );

and for error checking function returns where it is rarely if ever going to go wrong.

ret = OSGetTime( &currentTime );
ASSERT( ret );

There is a standard assert() macro in C, but I have my own set of ASSERT macros, they look like this:

#if defined( DEBUG )

#define ASSERT( cond ) if ( !( cond ) ) Lair::Assert( __FILE__, __LINE__, #cond, "" );
#define ASSERT_MSG( cond, msg ) if ( !( cond ) ) Lair::Assert( __FILE__, __LINE__, #cond, msg );
#define VERIFY( cond ) if ( !( cond ) ) Lair::Assert( __FILE__, __LINE__, #cond, "" );
#define VERIFY_MSG( cond, msg ) if ( !( cond ) ) Lair::Assert( __FILE__, __LINE__, #cond, msg );

// Assert - Assert (used by ASSERT macro)
void Assert(const char *file, const uint32 line, const char *expression, const char *message);

#else

#define ASSERT(cond) ((void) 0)
#define ASSERT_MSG(cond, msg) ((void) 0)
#define VERIFY(cond) ((void)(cond))
#define VERIFY_MSG(cond, msg) ((void)(cond))

#endif

VERIFY is like assert, except that where any code that runs as part of the expression being asserted is removed in FINAL builds, it remains in FINAL builds for VERIFY. These are equivalent, but one doesn't generate an unused variable warning:

bool tmp = LoadFile( configFile );
ASSERT( tmp );


VERIFY( LoadFile( configFile ) );

You don't want to do this:

ASSERT( LoadFile( configFile ) );

because the LoadFile will not be called in a FINAL build.

Assert is not the only thing needed to produce a bug-free program, but it is an important tool towards that goal. Sprinkle asserts throughout your code. You will be surprised by the ones that get hit. I've had asserts that remained true for months, then suddenly show up false in one particular circumstance. That's a hard to reproduce bug you've just found.

By Robert Basler on 2014-10-28 13:33:12
Homepage: onemanmmo.com email:one at onemanmmo dot com
Discovered that a call to __debugbreak() in each ASSERT macro right before the call to Lair::Assert() makes the debugger break right at the assert line. Better.

New Comment

Cookie Warning

We were unable to retrieve our cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.

You will not be able to post until you resolve this problem.

Comment (You can use HTML, but please double-check web link URLs and HTML tags!)
Your Name
Homepage (optional, don't include http://)
Email (optional, but automatically spam protected so please do)
Connery or Craig? (What's this?)

  Admin Log In



[Home] [Blog] [Video] [Shop] [Press Kit] [About]
Terms Of Use & Privacy Policy