On Tue, 14 Dec 2010 09:47:40 +0100, Stefan Götz <stefan.goetz@xxxxxxxxxxxxxxxxx> wrote:
Or do you mean I should consider it a runtime error and bail out gracefully?Personally, that's what I do because the idea is to have functions with as few side effects as possible. And 'terminating the application' is a massive side effect :-) Just because one particular function cannot handle one particular piece of input (e.g., NULL), it's a bit extreme to go berserk and suicide bomb the whole process, it should rather tell the caller that he's an idiot (in a nice way, like returning an error code) because he didn't adhere to the function call contract - at least that's my personal opinion.
But why use assertions at all then? To me, they're an efficient (because conditionally compiled) way of checking for inconsistencies that in theory shouldn't happen, as opposed to runtime errors (which, in case of _public_ functions, may well include passing a null pointer). After all, one strong point in using C is that, while demanding a certain discipline, it's possible to make assumptions about data that passed a certain code passage without testing the values more than necessary. I place assertions where I'm positive that appropriate checking has taken place on a higher level, which is only feasible for non-public functions of course. In a monolithic application, the notion of a public function can be arbitrarily blurred, yes. Which is why we disagree in the first place.
Now, I also realize how crashes suck extra much in unattended software like daemons... there should be a policy on this: avoid assertions (outside of tight loops perhaps) at all costs or not?
