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
>
>
>
>
>
