[openbeos] Re: My error handling philosophy

  • From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Tue, 06 Nov 2001 20:15:39 -0500

Very interesting post. I just want to remind everyone, though, that
BeOS doesn't use C++ exceptions. People can build them into
their own code, but BeOS (the OS) does not use them.

This is not the choice that I would make today, either. I know.
But that is what they did, and it is what we have to do, today.

>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 
>Store the "status" state in a global (or at least shared) variable/
>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 
>Document what outputs should occcur -- test those assumptions with 
>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 
>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.

Other related posts: