[bind10-dev] assertions, exceptions

[Nathanael Hoyle]

On Mon, 2010-05-24 at 05:28, Shane Kerr wrote:
> All,
> 
> I happened to notice the use of assert() in a recent review, and asked
> about it. Jinmei had some thoughts, which you can read in this comment:
> 
> https://bind10.isc.org/ticket/116#comment:4
> 
> Do we want to have any policies or guidelines about the use of assert(),
> or perhaps exceptions in general?
> 
> --
> Shane
> 

I've reviewed Jinmei's comments, which make a lot of sense, regarding
the rationale for using assert() in cases where the issue almost has to
be application internal and the benefit derived from a core dump. I'd
like to make a couple additional points, which I don't think Jinmei
addressed, and which are slightly non-obvious.

For development purposes, core dumps are great. This includes for
internal QA testing using debugging builds. For production deployments,
I think they are much less useful. A build done with something like:

./configure CFLAGS="-DDEBUG -ggdb -O0"

or similar, together with "ulimit -c unlimited", on a developers
machine, can yield a great core dump during testing. In production
usage, you're likely to find something more like:

./configure "CFLAGS=-DNDEBUG -O2 -fomit-frame-pointer -funroll-loops
-finline-functions"

together with core file generation disabled and a stripped binary.

As Jinmei noted, an assertion failure in the case under discussion could
really only be caused by a logic failure or data corruption (in memory,
or by the processor) on the system in question. While good code coverage
with test code can help reduce the likelihood of the former, one
consideration is that out "in the field" you probably won't get (at
least a useful) core dump. A backtrace from an exception handler would
at least point the investigation in the right direction. While a easily
reproducible failure could have the target system environment, and if
need be, build configuration, adjusted to enable usable core generation,
a rare or difficult to reproduce issue is easier to solve with an
exception trace than with no core dump and an application exit.

Therefore, I think part at least of the rationale for this should be
based on whether, broadly speaking, it is a goal to be able to receive
meaningful trouble reports from end users.

-Nathanael