(s)printf-style formatting and logging actual errors? about log15 HOT 10 CLOSED

https://github.com/inconshreveable/log15/blob/master/ext/handler.go

The EscalateErrHandler might be one way to deal with error types.

from log15.

You basically don't ever want to format values into your log messages, because then your data is no longer structured and can't be easily parsed by a machine. Instead prefer:

log.Info("some text", "max", max, "min", min, "someCtx", 42)

For errors, my own code uses 'err', usually like this:

f, err := os.Open(path)
log.Debug("open output file", "path", path, "err", err)
if err != nil {
    // handle error
}

I have considered allowing syntax to format the context keys into the message as well for additional human readability, but I haven't found I really needed it:

log.Debug("open %(path)s", "path" path, "err", err)

from log15.

Ok, good to know. "err" is a bit shorter than "error" indeed. Guess I'll use that. Thanks!

from log15.

Just found out that the context of child loggers doesn't override the content of a parent (because it's a slice, I just saw in the implementation). Should I re-create the necessary context each time?

from log15.

It appends to the context (or should at least) so:

l := log.New("foo", 1)
l2 := l.New("bar", 2)
l2.Info("test") // prints msg=test foo=1 bar=2

If you want a logger with less or no context, use the appropriate parent or the root logger, which always has no context. Does that make sense?

from log15.

Yes, my use case was this:

log := l.New("mod", "watcher", "fn", "main", "instance", 908632)

startSomeModule(log.New())

In this way, startSomeModule would override mod and fn everytime (by creating new subloggers, I hope this is not a very heavyweight operation to do on every function call), but the instance context variable would be kept (not overridden).

In any case, it's no big deal, I'll work around it.

from log15.

You want to create a new logger with the appropriate context whenever it becomes relevant, so for your use case:

logger := log.New("instance", 908632)
startSomeModule(logger.New("mod", watcherValue, "fn", fnName))

You could just pass the logger into startSomeModule and have it create the child logger there as well.

from log15.

You could just pass the logger into startSomeModule and have it create the child logger there as well.

That's what startSomeModule does, in fact. Like I said, it's a small change so no big deal :).

from log15.

awesome! closing this out

from log15.

Thanks for all the help!

from log15.