I think I have to agree with Morton. Were this anything other than a logging tool, I would flame Morton for inadequate test coverage. However, the log4net claims that it shouldn't throw exceptions, and there shouldn't be any argument here: Per log4net docs, this is a "serious bug".
In an Appeal to Authority, I quote log4net FAQ at: http://log4net.sourceforge.net/release/1.2.0.30316/doc/manual/faq.html "By fail-stop, we mean that log4net will not throw unexpected exceptions at run-time potentially causing your application to crash. If for any reason, log4net throws an uncaught exception, please send an email to the [EMAIL PROTECTED] mailing list. Uncaught exceptions are handled as serious bugs requiring immediate attention." The issue is what to do with the error data so that the information isn't lost. The options, as I see them. I prefer option 4 below. Option 0: Status quo - throw it. Violates log4net design objectives. Not "fail-stop". Option 1: Trap and ignore (as proposed by Morton) Advantages: Easy, conforms to "fail-stop" principle. Problems: Important log statements could fail, and you'd never know. Option 2: Configurable behavior If production environment, trap and ignore. If dev /test, throw. This allows users to discover failed exceptions. Configured, with default to "don't throw". Problems: Goofy and obfuscated. Option 3: Send error to console. Send all logger errors to console. This is currently done with configuration errors. Problems: Console is not always used or even viewable. (Where does stdout go in a web service? What if this is a very remote device?) Option 4: Send error to logger in use. This is easy and conforms to the fail-stop principle, without losing important log data. Send the error to the logger(s) in use with exception data, if the log is writable. That way, we are sure to be able to see it. Obviously, if we have an error writing to this log (can't open file, can't access database, etc) the log error has to go elsewhere - that's not the current bug, though. Ideally, there could be some configurable policy to allow use to escalate the log level (I treat almost all exceptions as ERROR or FATAL), but this is hardly necessary. PSEUDOCODE: void DebugFormat(string input, params object[] args) { if (IsDebugEnabled) { try { log(string.Format(input, args)); } // What if it is threadabort? Just throw? catch Exception ex { log("Bad format string " + input + ex.Message); } } Cliff Burger 2006/3/16, Morten Andersen <[EMAIL PROTECTED]>: > My point is that log4net should not throw exceptions what so ever. > > - Morten > > > Matthew Brown wrote: > Not that it matters to your original point, but I think that simple > concatenation of strings for the log statement is often a lot faster than > using String.Format anyway... > > > On 3/15/06, Morten Andersen <[EMAIL PROTECTED]> wrote: > > > > Hi! > > > > log.DebugFormat("Hello {0}! Where is {1}?, "Morten"); > > > > I know that I am missing an argument. The problem here is that some of my > applications went down because of this. > > > > > > > > -- > > > > > > Best Regards > > Morten Andersen > > Developer > > Vianett AS | [EMAIL PROTECTED] | Office: +47 69 20 69 74 | Skype: > mortander > >
