Open stephenmw opened 8 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?
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:
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:
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.