[bind10-dev] logging and exception

[Michal 'vorner' Vaner]

Hello

On Wed, Jun 22, 2011 at 11:56:19AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> 1. Ensure LOG_xxx never throws by not doing dynamic memory allocation
>    or not using throwing new, etc.  I'm afraid this is too costly and
>    makes the underlying implementation more complicated.

While this is a nice goal, I don't think it is doable. The .arg converts
whatever parameter to string (using lexical cast, which in turn uses operator <<
and stringstream I guess), it would be awful lot of problems to make all this
static allocated.

> 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.

> 3. Do not make logs in the context where an exception isn't supposed
>    to be thrown.  I don't think this is realistic or too restrictive.

I disagree with this one, as it stops doing useful logging under usual
circumstances in favor of an exception that never happens (see below).

> 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.
Kernel just sends SIGSEGV when it can't find a free page for the process. 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).

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.

With regards

-- 
I've already told you more than I know.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110623/0adcf183/attachment.bin>