Justin Erenkrantz wrote: > > There is one set of cases that I think asserts are possibly useful - > trying to isolate things that just shouldn't happen and you can't > reproduce it, but somehow it does happen. An assert should only be > present when you KNOW there is no way in hell that these things can > happen and you want to dump core to figure out how in the heck this > happened *or* you can't feasibly attached with a debugger with a debug > build. Things that might be handled or could be caused by the caller's > stupidity don't need an assert. >
OK, maybe we agree. There are a couple I put in where I felt we had dependencies on things that could break someday on some platform under some load conditions, and that would really be hard to debug without an assert. For example, in sendfile_it_all() (server/core.c in httpd-2.0) there's some hairy logic that does bookkeeping under partial write conditions, which is dependent on apr_sendfile working, which is dependent on every platform's sendfile implementation working correctly all the time. Well, guess what? Every once in a while this assert pops on FreeBSD (apache.org of course), and now I need to drill down closer to the OS (i.e. APR) and put in another one. There's no way in hell I can figure this out with a debugger as it stands. Other examples are in ap_getline() and ap_setup_client_block(). These popped intermittently in the past - this time due to our own bugs in error legs in the httpd 2.0 input filtering stuff. Ryan put in an assert that caught one of my bugs, and vice versa. > I think when Jeff and Greg Ames were debugging www.apache.org, they used > some asserts in httpd in a positive manner. well, thanks, but most of those are just "traps" looking for a particular symptom. We throw them away once we understand the problem and have a fix, and wouldn't put them into CVS. I don't think temporary traps are an issue. Greg
