FreeLists / openbeos / [openbeos] My error handling philosophy

["Daniel Reinhold" <danielr@xxxxxxxxxxxxx>]

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.