[
https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832632#comment-13832632
]
Michael Goldfinger edited comment on LOG4NET-409 at 11/26/13 3:00 PM:
----------------------------------------------------------------------
{quote}
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
{quote}
That's exactly what it should be, anything can be passed to the log methods.
You don't have to care about types when logging There is no reason to limit the
types that can be passed, and that's why it is object. An other reason I can
think of is that i have to know every type I want to log at design time. Which
is nearly impossible when you use anonymous methods and anonymous types. So in
the end I would fall back to ILog<object> just to be sure everything could be
logged.
{quote}
Sure, perhaps most people don't care, and perhaps most people will just send
strings and exceptions to their loggers. Maybe I am using log4net in a very
eccentric way and so maybe I am a one-off special case that you don't need to
worry about.
{quote}
I don't think so, I make heavy use if Custom ObjectRenderer. However you have a
very special case.
As far I understand your problem you use log4net the wrong way. Logging, in my
opinion should be implemented to help search for errors if something happens.
If for some reason the logging fails there should be no impact to the
functionality of an application. I seems to me that you have used log4net as a
notification service. This is something your own application should care about.
You could have used logging for additional information about that error and
send the notification inside your application logic, you should never use
logging to cover some of your application logic or functionality. This goes for
every logging framework out there.
I would also suggest to only use one ILog-Instance per class, if you in need of
an second one it's an indicator that you will do something that an logging
framework is not made for.
Well not everyone see this as strict as I do, and I'm not sure if my english is
good enough to transport my thoughts.
was (Author: swtrse):
{quote}
To be quite honest I think that any method that accepts an object type as a
parameter is dangerous. Because anything can be passed to it - any crap - and
there is no error, no exception thrown, nothing to suggest anything is wrong.
{quote}
That's exactly what it should be, anything can be passed to the log methods.
You don't have to care about types when logging There is no reason to limit the
types that can be passed, and that's why it is object. An other reason I can
think of is that i have to know every type I want to log at design time. Which
is nearly impossible when you use anonymous methods and anonymous types. So in
the end I would fall back to ILog<object> just to be sure everything could be
logged.
{quote}
Sure, perhaps most people don't care, and perhaps most people will just send
strings and exceptions to their loggers. Maybe I am using log4net in a very
eccentric way and so maybe I am a one-off special case that you don't need to
worry about.
{quote}
I don't think so, I make heavy use if Custom ObjectRenderer. However you have a
very special case.
As far I understand your problem you use log4net the wrong way. Logging, in my
opinion should be implemented to help search for errors if something happens.
If for some reason the logging fails there should be no impact to the
functionality of an application. I seems to me that you have used log4net as a
notification service. This is something your own application should care about.
You could have used logging for additional information about that error and
send the notification inside your application logic, you should never use
logging to cover some of your application logic or functionality. This goes for
every logging framework out there.
I would also suggest to only use one ILog-Instance per class, if you in need of
an second one it's an indicator that you will do something that an logging
framework is not made for.
Well not everyone see this as strict as I do, and I'm not sure if my english is
good enough to transport my explanations.
> Generics added to the Logger
> ----------------------------
>
> Key: LOG4NET-409
> URL: https://issues.apache.org/jira/browse/LOG4NET-409
> Project: Log4net
> Issue Type: Wish
> Components: Core
> Affects Versions: 1.3.0
> Reporter: Ben
> Labels: features
> Attachments: log4net.Generics Library.zip
>
>
> Maybe this has been suggested before - if so sorry (I did do a search for it).
> I am fairly new to log4net and when I am using it, I was surprised to see
> that the log methods take an object as a parameter. Of course this made
> sense after I found out that Object Renderers can be made to parse any type
> of object. I did wonder why Generics was not used.
> If I have an Object Renderer that knows how to log Orange objects then I
> don't want to accidentally pass it an Apple object (or any other type of
> object).
> So using Generics I would set up my logger as follows:
> private ILog<Orange> myOrangeLogger =
> LogManager.GetLogger<Orange>("OrangeLogger");
> I have just made a special type of logger that can log oranges. Instead of
> accepting parameters of type object it accepts only strings and Oranges.
> Behind the scenes the method
> LogManager.GetLogger<T>(string name)
> would return a logger of type ILog<T>.
> The ILog<T> interface would have methods on it like:
> ILog<T>.Warn(string message);
> ILog<T>.Warn(T message);
> ILog<T>.Warn(string message, Exception ex);
> ILog<T>.Warn(T message, Exception ex);
> but would NOT have the method:
> ILog<T>.Warn(object message);
> So now if I tried to pass it an Apple object I would get a compile error
> rather than the default behaviour for a logger which has been given an object
> that has no special renderer (in fact I probably wouldn't even realise until
> I went to look at the log files right?). This would be much better and would
> help to save me from embarrassing myself in front of my customers.
> This could be added in addition to the standard loggers which would still be
> returned in the normal way using:
> LogManager.GetLogger(string name);
> If this has not already been suggested then I hope you like this idea.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
