[bind10-dev] logging and exception

[JINMEI Tatuya / 神明達哉]

At Thu, 23 Jun 2011 08:33:56 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > 2. Similar to #1, but simply catch any exception from the logger and
> >    ignore it:
> > #define LOG_DEBUG(LOGGER, LEVEL, MESSAGE) \
> >     if (!(LOGGER).isDebugEnabled((LEVEL))) { \
> >     } else { \
> >         try { \
> >           (LOGGER).debug((LEVEL), (MESSAGE)); } \
> >     } catch (...) {}
> >    I don't like this either, but in this context it may be a least
> >    evil and acceptable option.
> 
> This, again, would be problematic, because of how the .arg is done. They would
> be out of the call. We can catch exceptions inside of them, when replacing the
> string, but the conversion is hard to cover.

Ah, okay.  So it will be trickier than I first thought.

> > 4. Pretend the problem doesn't exist and ignore it because the
> >    exception in question would normally only happen in rare cases such
> >    as memory shortage.  This may be acceptable as a compromise, but
> >    I'd rather prefer #2 than this one.
> 
> I think, as the only expected exception is std::bad_alloc, this
> should be OK. On Unix systems, it is common malloc never returns
> NULL and new never throws (with exceptions of running out of address
> space), because of lazy memory allocation.
[...]

I've seen malloc return NULL in BIND 9 for a very busy caching
server.  Even though various environmental conditions are different
between BIND 9 and BIND 10, and so the BIND 9 case may not directly be
mapped to BIND 10, I would say it's naive to rely on assumptions that
give us an easy excuse.

> And even in situation when we get that exception, what do we do? Is
> it realistic to think we would ever try to catch that (with some
> exceptions of catch-alls, which usually just convert to different
> kind of error and throw again or terminate), so it will terminate
> the application (and, if not this one, the next one for sure,
> because if we run out of memory, next allocation will likely fail
> too).

If and when bad_alloc happens, I suspect we'd end up terminating the
program in many cases (probably immediately after catching it at the
highest level of the program).  But the point is that we do this along
with an exception propagation flow where an exception is expected
(even though it may be very rare).  On the other hand, if we let an
exception happen where it should never happen, the program may be in a
totally broken state, and, even worse, may cause externally observable
bad effect such as leaving a database in a broken state.  Ultimately
this is still a cost-benefit tradeoff, but I personally wouldn't
underestimate the damage by not handling this properly.

That said,

> I believe we have much bigger problems in the code than badly
> handled bad_alloc exception. Every other file I open contains a
> FIXME, XXX or something we are aware of, and we have many problems
> we are not aware of. So, I think this has quite a low priority.

I never said it's a high priority issue:-) I guess everyone (including
myself) thinks it's a non urgent, low priority thing (although, again
personally, I think this one would be more important than some other
XXX things).  To claim it to be "production ready", however, I'd argue
this should be solved by the end of Y3.

Note also that it's not just "badly handled bad_alloc exception".
It's "badly let (bad_alloc) exception be thrown when an exception
should never happen in the first place".

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.