List Info

Thread: Log4net throws exception




Log4net throws exception
user name
2006-03-17 01:50:19
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:rongrabowskiyahoo.com] 
Sent: Thursday, March 16, 2006 5:37 PM
To: Log4NET Dev
Subject: Re: Log4net throws exception

--- Cliff Burger <cliff.burgergmail.com> 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 ",
"World"); logFormat.DebugFormat("Hello
", "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

Log4net throws exception
user name
2006-03-17 01:59:57
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) <ge.com">Richard.Ruppge.com>; 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:yahoo.com">rongrabowskiyahoo.com]
Sent: Thursday, March 16, 2006 5:37 PM
To: Log4NET Dev
Subject: Re: Log4net throws exception

--- Cliff Burger <gmail.com">cliff.burgergmail.com> wrote:

&gt; "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(&quot;Hello World";);
logArgs.DebugArgs("Hello ", "World"); logFormat.DebugFormat("Hello
", "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


[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )