I agree wholeheartedly....
If it gets into something like the scenario mentioned below, maybe the
logger can put a syslog entry, or console/stderr output (as configured by
the user in some global setting)?
Renny Koshy
[EMAIL PROTECTED] (J.T. Conklin)
09/23/2008 01:12 PM
Please respond to
"Log4CXX User" <log4cxx-user@logging.apache.org>
To
"Log4CXX User" <log4cxx-user@logging.apache.org>
cc
Subject
Re: File system full causes log4cxx to crash
"Jacob L. Anawalt" <[EMAIL PROTECTED]> writes:
> I am glad it worked out for you. At the same time I am concerned that
> you had to do this and I didn't. I would like to reproduce the problem
> so that I can handle it, preferably without putting try/catch around
> every logging statement...
Some time back, I sent a message to the list asking what the behavior
of an appender that throws an exception should be. As it is, a stray
exception can unwind all the way through the library into the calling
code.
To my mind, wrapping log invocations with try/catch blocks isn't a
completely satisfactory solution, as if you have multiple appenders
associated with a logger, the exception will prevent subsequent
appenders from being invoked.
Personally, I think log4cxx should provide a guarantee that a log
invocation will not throw an exception under any circumstances. One
of the common use cases for emitting a log event is when you're in a
error handling path, the last thing you want to worry about is the
logging framework making hash of things.
Two alternatives that come to mind are that every appender's append()
method needs to have a try/catch block to squelch any exceptions, or
that the appendLoopOnAppenders should have a try/catch block around
each call to doAppend() invocation. Or since all it takes is one bad
appender (and even if all appenders that are distributed with log4cxx
are fixed, there's no guarantee that user's appenders will also be), a
hybrid of the two approaches where the try/catch block around
doAppend() logs an internal message about the unhandled exception.
Basically, a framework shouldn't allow a callback to subvert or
compromise the function of the framework itself.
--jtc
--
J.T. Conklin
