Here is how I currently log any exceptions that occur in my code:

  1. Pass each object instance the path to a file where I want all of the logging to happen.
  2. Each of the objects have their own exception logging code, which is called in a finally statement.

One downside I could see to this, would be that if I had to make a change to the way that logging is done. In the case that I needed to change something with the logging, it wouldn't take place in all of the objects.

On the other hand, now it's not like every single one of my libraries depends on some error-logging library just to compile.


Am I going about this the wrong way? Is all of the error logging actually supposed to be in its own library?

  • If you're writing a library, should it even do logging? Usually having events to which the consumer can subscribe is a better approach. Commented May 4, 2016 at 12:29
  • @CodesInChaos Okay I see. No I don't think so, I think the library should be responsible for certain things that are related. It's just... the way i've always done it is where the library performs it (doesn't make it right obviously). So would you launch some event from the finally clause and then consume it from a subscriber?
    – Snoop
    Commented May 4, 2016 at 12:34
  • When an error happens, a typical library throws an appropriate exception and passes the responsibility of handling it to the caller. The libraries I work on rarely have warning conditions, so I don't get into the situation where I have to think about logging. But if really necessary, I'd use events instead of doing any concrete logging in the library, in the worst case an Action<string> with the log message, but preferably a domain specific event like "ConnectionTimeout` or whatever. Commented May 4, 2016 at 12:39
  • @CodesInChaos looks like I need to get out the sleeping bag, I'll be spending the night at work fixing what I messed up.
    – Snoop
    Commented May 4, 2016 at 12:40
  • It's difficult to give good advise without knowing the context. My experience is mainly with BCL like libraries which contain algorithms or data structures. For other kinds of libraries different concerns might apply. For example if your library is more like an application module/plugin, logging may be appropriate, but in that case I'd expect the targeted application to have chosen a logging framework exposing a logging API to plugins. Commented May 4, 2016 at 12:44

1 Answer 1


Don't you want to abstract out this functionality ? e.g. you may want to log to a file, to a network socket, to stdout etc. I certainly don't think that your classes should know about files etc. but about an abstract logger, and you can decide later how this is going to work.

This is a very common requirement, and you'll find libraries already exist to do this e.g. log4net. These libraries are typically configuration-driven and you'll normally instantiate a logger via a static factory method or similar. Your classes will know about a logger class, but beyond that they won't normally be concerned where or how they're actually performing the logging.

  • Yes, definitely feel there may be a need. Which is why I asked. Thank you.
    – Snoop
    Commented May 4, 2016 at 12:31
  • I would definitely go this route. You classes show know how to call a logger, they shouldn't know the details of how it's done. Look at Common.Logging, log4net, nlog,... I like to pass the Logger abstraction in as a constructor argument and have a DI container wire everything. See Castle.Logging
    – Fran
    Commented May 4, 2016 at 13:57
  • @Fran I understand that DI is a large part of the .NET world, and I know I need to read-up. Will be doing that soon, thank you for your insight.
    – Snoop
    Commented May 4, 2016 at 14:10
  • 2
    There is also System.Diagnostics.TraceSource if you need/want to avoid pulling in additional dependencies. You can attach different listeners to log out to different locations either programmatically or through app.config files.
    – Dan Lyons
    Commented May 4, 2016 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.