Since Erik brought this up, I can't help resist but to throw in my own theory of error handling. This is quite a bit more than Erik asked for, but oh well... At the risk of sounding like an idiot (or a genius, take your pick), I would say the best error handling policy is "don't make errors!". Before anyone starts throwing rocks at me, let me point out that "error" is in the eye of the beholder. All programs and subprograms have inputs and outputs. You should know what outputs occur for what inputs... if you do, then you don't really have errors at all. If you choose to call one of those outputs "BError" or something like that, fine, whatever makes sense. To me, the only real errors are when, for example, Fred's function returns the value 77 and Fred has no clue why. In other words, a bug. If he knows that a certain input induces an unwanted scenario and has the function return a negative value (for example) to indicate an error condition, to me that is not so much an error as an exceptional condition. The programmer knew of the unusual condition that could occur and had code in place to handle it. Therefore when talking about error handling, we're really talking about two different things: exception handling, and debugging. Exception handling is all about strategies for dealing with non- standard code paths. Debugging is about trying to figure out why your program says 2+2=5. Returning "error" codes falls into the category of exception handling. It's an unwanted condition, but you knew about in advance and dealt with it by returning a magic token. As long as everyone know this, there is no problem. This just falls under proper documentation. Of course, if it's possible to rewrite the function somehow so that the unwanted scenario can't happen in the first place, that is even better. Debugging can be a mystifrying (no that's not a typo) ordeal, altho it's worth it if it helps the programmer realize the gap in his understanding. All bugs are ultimately the result of the programmer not understanding his code (whether it's his own code paths, or the interactions with others). Bugs remind us that our brains are finite and fallable. Your best defense is to write simple code (note, I did not say 'simplistic'). Simple code is short, obvious, and has clean, well-defined interactions with other routines. Exception handling strategies: ------------------------------ Return an error code Use boolean functions (return false) and put the error info in a parameter Store the "status" state in a global (or at least shared) variable/ buffer Try/catch/throw blocks in C++ as a recovery technique DO NOT do any error reporting in a library function (let the caller decide what to report) Debugging strategies: ------------------------------ Test each function independently Document what inputs should occur -- test those assumptions with assert() Document what outputs should occcur -- test those assumptions with assert() Trace the call stack and data values to screen during runtime -- you know, printf() Trace the call stack and data value to a log file during runtime Break complex functions into several smaller functions Give your function ridiculous values for inputs Test every boundary (min, max values for numbers -- first, last indexes for arrays...) Explain to someone else how your function is supposed to work (step by step) Rewrite your function using a different algorithm and compare I'm sure I've left out a few useful techniques, but you get the idea. The main point I'm trying to get across in all this drivel is that there is no magic bullet with respect to error handling. No methodology that we might adopt will take the place of good coding practices, good testing, and good documentation.