logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Goldfinger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4NET-409) Generics added to the Logger
Date Tue, 26 Nov 2013 14:58:36 GMT

    [ https://issues.apache.org/jira/browse/LOG4NET-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832632#comment-13832632
] 

Michael Goldfinger commented on LOG4NET-409:
--------------------------------------------

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

Mime
View raw message