Logging from a specific place in code helps with finding out *where* the
error happened. And doing that manually is cumbersome. I for one can not
give-up on this because it makes fixing things super fast.
Fortunately current logging packages (like zap) take care of that case by
providing the option to register them as the output for the standard log
package - all at info level.
On Thursday, August 17, 2017 at 11:36:54 AM UTC+4:30, Peter Mogensen wrote:
>
>
>
> On 2017-08-15 21:34, Tamás Gulácsi wrote:
> > Even better: my libraries expose only the LogFunc: i.e.
> > var Log = func(keyvals ...interface{}) error { return nil}
> >
> > Which is easy to override with any logger, is not tied to go-kit/log,
> but provides structured logging!
>
> ... or exposing some lib.SetLogger(...) function.
>
> But preferably, one should try not to log from libraries and return
> errors instead and leave logging to the application - if possible.
>
> There's few things more annoying than libraries spitting something out
> where you least need it.
>
> /Peter
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
