Chuck Esterbrook wrote:
On Jan 16, 2008 8:01 PM, Christopher Smith <[EMAIL PROTECTED]> wrote:
So, when a process can no longer log successfully, you'd rather keep
it running than let it die, so it's parent can report the problem and
spawn a new child?!?!
No. When logging throws an exception, the exception gets caught and
logged.
/me just let's the logic of that sink right in. :-)
First, let me take this opportunity to apologize for the spurious use of
an apostrophe there. It should of course be "lets" instead of "let's".
One might say: "When logging throws an exception, the exception gets
caught and logged in a different, more simple way." I've used exactly
that technique in Python projects and it works. My fancer logger
choked and the primitive logger kicked in and succeeded.
Now maybe the primitive logger fails, but then nothing is perfect.
I'm not sure if this is a misunderstanding of exceptions or destructors,
or the exception-destructor interaction, but this is the second post
that has suggested this approach.
It's not the *throwing* exceptions inside a destructor that is a
problem. You can and should do that as appropriate. You just can't let
exceptions bubble past the destructor. So, in the case where your
logging framework encounters an error and therefore an exception is
thrown, it might very well recognize a way to address the problem by
routing a message to a more primitive logger. Now, if that is the case,
the logging framework itself should catch the exception and resolve the
problem accordingly: because it has found a way to resolve the
exceptional case. Indeed, a good logging framework will completely
ecapsulate the notion of distinct/multiple appenders from the
application code.
Now, I could see where some inept programmer might choose to let the
application manage this logic, but such behaviour should not be expected
or appreciated much. If I were using a logging framework that did this,
I'd not use it. If I had to, I'd write my own layer on top which handled
this logic and use *that*, rather than use the logging framework itself.
It's not quite the same thing, but it can be a helpful tool for
optimizing GC as well. My point is, all compilers fail to warn or
enforce good conventions. It is the nature of the beast.
That's no longer true. Cobra warns and enforces various conventions
and will continue to do so.
Some, but not all. That's as much as one can hope for. Andrew originally
suggested that it was a flaw in the language to have rules/idioms like
"always do X" that weren't enforced by the compiler. In practice "always
do X" rarely means "*always*" or "*X*" precisely, and often is
imprecise enough that it'd be a mistake for the compiler to generate
errors and difficult for it to generate warnings when such rules are
violated.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
