Asserting a Coding Style

There are two schools of thought regards how your code should fail: either it should try to keep going as best it can, or it should hard stop.

After many years in IT, I'm firmly in the hard stop school. It makes it far easier to debug, if your program fails at the point at which an exception occurs, even if it is a less pleasant experience for your users. (And trust me, trying to talk someone on Windows through setting up a debugger is not easy - I mean, I can't even do it for myself at the moment).

The 'try to keep going as best it can' is often a euphemism for silently corrupt something, violate the assumptions we've got in the code and then fail inexplicably further down the track.

Luckily for people playing the game, Unangband, like Windows, is written to the silently corrupt and experience weird errors standard. Which is why I have in the back of my mind, the intention to adopt a coding standard that promogulates hard failure when it detects an exception.

The easiest way to do this is have an ASSERT() macro which if false, does something that'll cause general program fault, like dividing by zero. ASSERT is used in a couple of places in the Unangband source, where my more disciplined co-developer has attempted to impose some kind of rigor in the codebase.

What has piqued my interest and led me to discuss this, is a new dungeon generation algorithm posted on rec.games.roguelike.angband. This algorithm has been kindly put into the public domain by it's developer Kusigrosz, and you'll be seeing it at some point in Unangband as a new room type, nest and as a new dungeon theme. (Screen shot of the output either at the link or the start of this article).

The C source for this algorithm uses another macro REQUIRE() which if false, immediately exits the program and dumps the source code line at which the fault occurs. REQUIRE() is like ASSERT() in that it lends itself naturally to specifying the pre-requisites and post-requisites for a function. You can for instance add a line REQUIRE(x>0); which intuitively indicates that at this point in the code we expect x>0.*

What I ideally would like, is REQUIRE() but with the ability to set a failure level at compile time or run time. That way I could have a number of differing levels of failure, allowing the user or distribution to select how hard they want the program to fall over. The levels would be:

0. REQUIRE() compiles out completely, used on systems with limited memory or performance.
1. Silently return from the function.
2. Write a warning to a log file, and silently return from the function.
3. Write an error to standard out, including the line number of the source code and exit.
4. Dump the stack to a file, including the line number of a source code and exit, useful for a debug build for users who don't have the technical skill to set up a debugger.
5. ASSERT().

I'm quite happy to be able to bloat the source doing this in the long term, but I want to make sure I'm doing so with a robust mechanism.

So my questions are:

1. Is there any other mechanism out there that better supports this hard, flexible fail over?
2. What is the best C constructions to ensure levels 0 and 1 work in a platform independent manner? Remember, I don't know necessarily whether the function is intended to return anything at all.
3. Is there any macros or public domain code that supports dumping the stack at runtime? This would also need to be relatively platform independent. Note that Windows is the only platform where this is currently a major problem.

Thoughts and feedback welcome.

* The Unangband form of this, adopted from Angband, is as follows:

/* Paranoia */
if (x < 0) return;

which is very much of the form 'silently fail and keep going'. [Edit: And you'll see here, prone to failure. Of course, I meant if (x <= 0). But then out by one errors are always fun]. [Edit 2: And it also looks like I reversed the conditionality of the assert() statement, in which case assert() and require() are equivalent. Article amended. And I should read assert.h].

Similarly, the TRY {} CATCH construction is mostly focused on trying to recover from exceptions.