Logging Contrarian

I'm a logging contrarian. Instead of each object declaring and using its own logger, I'd rather have objects that just expose formal notifications to the outside world. The objects shouldn't be concerned about how the notifications are presented or consumed. To me, this is just basic separation of concerns.

Steve Freeman has a couple of great posts (here and here) that provide collaborating information and ideas. I especially like his take on support vs. diagnostic logging and logging design:

The idea of encapsulating support reporting sounds like over-design, but it's worth thinking about for a moment. It means I'm writing code in terms of my intent (helping the support people) rather than the implementation (logging), so it's more expressive. All the support reporting is handled in a few known places, so it's easier to be consistent about how things are reported and to encourage reuse. It can also help me structure and control my reporting in terms of the application domain, rather than in terms of java packages. Finally, the act of writing a test for each report helps me avoid the "I don't know what to do with this exception, so I'll log it and carry on" syndrome, which leads to log-bloat and production failures because I haven't handled obscure error conditions.