[hipl-dev] Re: [Merge] lp:~diego-biurrun/hipl/hipfw-performance into lp:hipl
- From: Tobias Heer <heer@xxxxxxxxxxxxxxxxx>
- To: hipl-dev@xxxxxxxxxxxxx
- Date: Tue, 14 Dec 2010 13:59:15 +0100
Hi,
Am 14.12.2010 um 11:33 schrieb Christof Mroz:
> 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?
>
In my opinion, one has to clearly distinguish error handling from debugging.
Assertions are for debugging only. They are good to find bugs quickly and in
time. And they show you the error very drastically - by terminating the
application. In natural language they spell "This must never happen. If this
happens, the software is broken and does not deserve to run."
I believe, assertions should NEVER be used for error handling in the sense that
an unwanted/unexpected but still possible input (e.g., some information that
was read from a config file, that was received in a network packet, that was
read from the command line... or originates from any other external event (lost
packet,...)) can terminate the application via an assert. In this case, the
software is not broken but the interaction with other software (local or
remote) or the user is broken. Terminating the locally running piece of
software does not help here. In such case you need error handling (log
messages, special behavior, etc).
Just my two cents.
Tobias
Other related posts:
