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