Log4net throws exception

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:cliff.burgergmail.com] 
> 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 
> log4net-userslists.sourceforge.net 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 <mortenvianett.no>:
> >  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 <mortenvianett.no> wrote:
> > >
> > > Hi!
> > >
> > > log.DebugFormat("Hello ! Where is
?, "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 | mortenvianett.no | Office: +47 69
20 69 74 | Skype:
> > mortander
> >
> >
>