Thanks for making the change. It looks like Morten applied the try/catch to only one of the overloaded DebugFormat methods. What about the other method that takes a IFormatProvider? Can try/catch be added to the Fatal, Error, Info, and Warn format methods as well?
-----Original Message----- From: Ron Grabowski [mailto:[EMAIL PROTECTED] Sent: Thursday, March 16, 2006 7:03 PM To: Log4NET Dev Subject: RE: Log4net throws exception This is ok: log.Debug("Hello{0}World{1}Today", null, null); The problem is when you give it a malicious format string: log.DebugFormat("Hello{{,,,5}World{8}Today", "foo", "bar"); The try/catch addition seems to be the simplest fix. --- "Rupp, Richard (GE Healthcare)" <[EMAIL PROTECTED]> wrote: > I would debate it is more than annoying if a production application > crashes because of this type of exception. It seems likely application > data passed into the format method could be null. > > If I need to check for null values or catch exceptions when I use the > API then it is not fail-safe. If I need to write a front-end to > protect my application from the exception I question why it is not > built into the API. > > _____ > > From: Matthew Brown [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 16, 2006 6:00 PM > To: Log4NET Dev > Subject: Re: Log4net throws exception > > > As Ron said, I would argue that this is an expected exception, at > least as a user who has always assumed that log4net would use > String.Format under the covers. > > It might be annoying, but this kind of error makes itself obvious the > first time any code path with this call in it is hit. > > > On 3/16/06, Rupp, Richard (GE Healthcare) <[EMAIL PROTECTED]> > wrote: > > The problem is not that String.Format is throwing an uncaught > exception, > that is an implementation detail. The problem is that the API has > thrown > an exception and it is suppose to be fail-safe. > > The multiple interface idea complicates the API. > > What is wrong with Option 4 suggested by Cliff Burger > (16-Mar-2006 3:28 > PM)? > > -----Original Message----- > From: Ron Grabowski [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 16, 2006 5:37 PM > To: Log4NET Dev > Subject: Re: Log4net throws exception > > --- Cliff Burger <[EMAIL PROTECTED]> wrote: > > > "By fail-stop, we mean that log4net will not throw unexpected > > exceptions at run-time potentially causing your application to > crash. > > The documentation for String.Format says that if the format is > invalid > or the number indicating an argument to format is greater than or > equal > to the length of the args array a FormatException will be thrown. If > I > passed an invalid format to the function, I expect to get an > exception. > I don't think that's too unreasonable. > > If you're passing incorrect formats to the *Format methods my > response > would be to stop using incorrect formats or stop using the methods > that > accept formats. If know you get burned when you touch hot > coals...don't > touch hot coals. > > That being said...one option would be revert ILog back to its > non-Format > state and add additional interfaces like ILogFormat and ILogArgs with > the caveat that they may throw expections if passed malicious/invalid > arguments. > > ILogFormat would contain the DebugFormat style methods. ILogArgs > would > contain the ~18 overloads that Console.Out.Writeline does. > ILogArgsFormat would contain a combination of both. If the LogManager > returned ILogArgsFormat, I think you'd be able to use one of the more > restrictive interfaces without having to cast (I haven't tested > this): > > ILog log = LogManager.GetLogger(typeof(MyClass)); > ILogArgs logArgs = LogManager.GetLogger(typeof(MyClass)); > ILogFormat logFormat = LogManager.GetLogger(typeof(MyClass)); > ILogArgsFormat logArgsFormat = LogManager.GetLogger > (typeof(MyClass)); > > log.Debug("Hello World"); > logArgs.DebugArgs("Hello {0}", "World"); logFormat.DebugFormat("Hello > {0}", "World"); > > That's a bit messy but it would give you more control on whether or > not > you want your application to use potentially dangerous methods. > > - Ron > > > > >
