I would favour doing both 3 and 4. That is log as much as can be logged through the appender as configured by the user. This information may be important to them. Also log the failure in the internal log, which currently goes to the console and debug out.
We need to write a save version of the String.Format with the same expected behaviour, but handling any exceptions. Also we need to handle exceptions other than the FormatException as there is no guarantee which exceptions will be thrown. Nicko > -----Original Message----- > From: Cliff Burger [mailto:[EMAIL PROTECTED] > Sent: 16 March 2006 23:28 > To: Log4NET Dev > Subject: Re: Log4net throws exception > > 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 > > > > >
