Before you consider this package, please read this blog post by the inimitable Dave Cheney. I really appreciate what he has to say, and it largely aligns with my own experiences. Too many choices of levels means inconsistent logs.
This package offers a purely abstract interface, based on these ideas but with a few twists. Code can depend on just this interface and have the actual logging implementation be injected from callers. Ideally only main()
knows what logging implementation is being used.
The main differences are:
fmt.Printf()
. I disagree, especially when you consider things like output locations, timestamps, file and line decorations, and structured logging. I restrict the API to just 2 types of logs: info and error.Info logs are things you want to tell the user which are not errors. Error logs are, well, errors. If your code receives an error
from a subordinate function call and is logging that error
and not returning it, use error logs.
This is a BETA grade API. I have implemented it for glog. Until there is a significant 2nd implementation, I don't really know how it will change.