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