[pulseaudio-discuss] Usage of pa_assert

[Lennart Poettering]

On Tue, 08.11.11 20:45, Maarten Bosmans (mkbosmans at gmail.com) wrote:

> 2011/11/8 Tanu Kaskinen <tanuk at iki.fi>:
> > On Tue, 2011-11-08 at 09:00 +0100, David Henningsson wrote:
> >> In short, assertions are better than nothing, but proper error handling
> >> is better than assertions.
> >
> > In my opinion assertions are proper error handling when the error in
> > question is a programming error in our own code.
> 
> Indeed. There aren't many cases that just ignoring the failure and
> carrying on like nothing happened adds much value over just hitting
> the assert.
> 
> So do we have an official recommendation for distributors to leave
> asserts enabled in production builds? I don't care much either way.
> David seems to think it's the right thing to do.
> 
> I do think that fast-path asserts (pa_assert_fp) should be disabled,
> except for developer builds. There's a reason these asserts can be
> enabled or disabled independently from normal asserts and although the
> current code doesn't use them much, there's already a patch of me (for
> the trivial resampler) that makes very good use of a fast-path assert.

Yes, normal asserts should be enabled in distro builds. fast-path
asserts should be disabled in distro builds. In debug, test and
developer builds fp asserts should be enabled too.

In some super-optimized embedded builds you can disable all asserts. But
general purpose distro's shouldn't do that, unless they are into snake
oil, and don't understand what's funny about
http://funroll-loops.info/...

In general asserts should be used to detect programming errors while
prpoer error handling is the right choice for runtime errors. Of
course, sometimes the border between the two is blurry, in which case
one should lean towards proper error handling.

But yupp, there's nothing bad about asserts, if you use it
properly. Think a bit of what kind of error you have there, and then use
asserts, and don't feel bad about it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.