I'll add my own agreement to this. It's not acceptable for a logger to
crash an application when the volume becomes full. My solution to use a
try/catch works for us for now since we only have a single appender, but
as was mentioned below if we decided to add a second appender the
try/catch is a very big hammer, potentially preventing the other
appender from running. Still, it's better than the application crashing
on us.


Sent: Tuesday, September 23, 2008 10:20 AM
To: Log4CXX User
Subject: Re: File system full causes log4cxx to crash


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


09/23/2008 01:12 PM 

Please respond to
"Log4CXX User" <log4cxx-user@logging.apache.org>


"Log4CXX User" <log4cxx-user@logging.apache.org> 



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 

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.


J.T. Conklin

Reply via email to