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