[pulseaudio-discuss] [PATCH 2/6] Turn device ports into reference counted objects

David Henningsson david.henningsson at canonical.com
Tue Nov 8 12:17:04 PST 2011

On 11/08/2011 06:41 PM, Tanu Kaskinen wrote:
> On Tue, 2011-11-08 at 09:00 +0100, David Henningsson wrote:
>> On 11/03/2011 07:33 PM, Tanu Kaskinen wrote:
>>> This looks good too. I'd really like the pa_device_port_hashmap_free()
>>> function behavior change to match all other *_free() functions, though.
>> I do acknowledge the consistency argument, but I think we're over-using
>> asserts in this project in general. From a development perspective, it
>> might be useful, but from maintaining PA downstream, I'm tired of PA
>> crashing every time something happens that the developer did not
>> anticipate.
> Are Pulseaudio crashes due to unnecessary asserts really that common
> nowadays?

Out of 84 (!) open bugs for PulseAudio in Ubuntu 11.10, 8 of them are 
assertion failures (i e starts with "PulseAudio crashed with SIGABRT").

(And some of the 84 might be driver bugs, user failures and such, but 
still I think 84 is quite a lot)

Whether these asserts are necessary or not is a different question.

>> Especially in destructors like this one, we should could try
>> to free what we can instead of crashing.
>> 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.

Eh, I'd say proper error handling is to fix our own code's programming 
error! :-)

I'm not saying we should never use asserts, but I think we over-use 
them. (And a lot of this goes back to Lennart's code as well.) Instead 
of going the extra mile and thinking "hmm, what if this could actually 
happen, what should we do in that case?", I suspect that sometimes we 
just put in an assert instead, just out of laziness, and see if anyone 
ever complains about it. True or not?

David Henningsson, Canonical Ltd.

More information about the pulseaudio-discuss mailing list