[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.
http://launchpad.net/~diwic
More information about the pulseaudio-discuss
mailing list