Well done.

Ummm… try as I might I don’t see any references to Windows 98 or XP in the article

http://marknelson.us/1992/05/01/file-verification-using-crc-2/

Tell me, why did you post the comment here instead of in the comments section on that article?

- Mark

You article “File Verification Using CRC” is dated May 1992,
but in the article you refer to Windows 98 and to Windows XP.
Is there an error in the dating of the article?

DBG_ERROR( “can you believe this: ” << someString << “is not null!?” );

I prefer the sprintf format but that is still pretty clean.

The next part was just an obvious point that DBG_ASSERT could expand to your example code or several other forms. That is it’s chief strength above your example.

The sprintf format is just one example. I’ve also seen DBG_ERROR( “can you believe this: ”
DBG_ASSERT( !somethingBad, “Fatal error message” )

can easily be expanded to:

if (something bad)
throw FATAL_ERROR


or to several other better implementations.

I won’t argue that there isn’t more than one way to skin this cat – although these two approaches seem fairly equivalent to me.

A minor note: the DEBUG_ASSERT you show uses sprint() type argument formatting, and one of the reasons for this particular class was to be able to take advantage of std::ostream formatting – not that DEBUG_ASSERT couldn’t have a version that does this.

As for fatal error handling in production program, DEBUG_ASSERT may or may not ultimately throw, which we hope will unwind the stack and clean up as much as possible on exit. If DEBUG_ASSERT wraps up by calling assert(), you are hosed on production.

As for picking up the __FILE__ and __LINE__, that can be done pretty easily here too – although it obviously requires invocation of the preprocessor, so your code looks like this:
[cpp]
if (something bad)
throw FATAL_ERROR


DEBUG_ERROR( "Uh oh, if your in this branch your broke!" );
DEBUG_ASSERT( pObj, "Null pointer!" );
DEBUG_ASSERT( a == b, "a doesn't equal b cause b is %1", b );


I think you will find this method provides the benefits of your approach plus much, much more.

In languages that do not support C pre-processor style macros, I use a wrapper around throw to achieve the same thing.

Consider this to be a replacement for assert(). If you look at the one minor example, you’ll see that I throw an exception when command line arguments are missing. Not really a bug in my program, but a good reason to stop.

This kind of exception can only really be used when your program is more or less sane. It is not likely to be useful in a case where your program loses its sanity. For one thing, this is usually not something you can predict, so you aren’t going to be writing conditional code to detect the condition and throw an exception.

So this is useful for things like “file not found”, “unable to open network port”, “database appears to have lost consistency”. Not so much for bad pointer, memory leak, mismatched libraries, etc.

It’s just one tool among many that you might use to handle errors in a production program.

I prefer that my programs actually crash at the point of a fatal error. It allows customers to create and send crash dumps and allows me to see exactly what was happening at the point of failure. Any ‘fatal condition’ handling loses some data that would help in diagnosing.