inconshreveable / log15

Structured, composable logging for Go
https://godoc.org/github.com/inconshreveable/log15
Other
1.1k stars 144 forks source link

Support for convenience functions #110

Open stephenmw opened 8 years ago

stephenmw commented 8 years ago

I am new to log15 and currently evaluating it for a new project. One of the first things I did was make a convenience functions that would allow logging from contexts (in an http server). Example:

func Error(ctx context.Context, msg string, logCtx ...interface{}) {
    FromContext(ctx).Error(msg, logCtx...)
}

The problem is that the convenience function is the caller of logger.Error and therefore anything relating to the file and line numbers is less than useful. Now, if I wanted to, I could create a handler that fixes this, but the problem is I don't know that logging will always be done from one of my convenience functions. In fact, I expect it to often not be. I propose the following method be added to log15.Logger interface:

Write(msg string, lvl Lvl, ctx []interface{}, call stack.Call)

This would allow my convenience functions to work while not breaking anything. I would be happy to submit a PR if you agree to the change. Also, wording is open to change.

stumo commented 6 years ago

I've got similar issues - I want to use log15 for a library that accepts a Func(string) as its logging function, so at the moment all my logs are coming out with the wrapper function's location.

I think that if the existing stack depth can be exposed, then most of what you want can be dealt with by creating a new logger. E.g.

loggerWithAdjustedStackDepth := log.New()
loggerWithAdjustedStackDepth.SetStackDepth(log.GetStackDepth() + 1)

loggerToPassToLibrary := func(s string){

loggerWithAdjustedStackDepth.Debug(s)
}

Is there any reason not to allow getting the current stack depth?