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.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] (J.T. Conklin) 09/23/2008 01:12 PM Please respond to "Log4CXX User" <firstname.lastname@example.org> To "Log4CXX User" <email@example.com> 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