Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AddCaller hook can't be wrapped #40

Closed
akshayjshah opened this issue May 4, 2016 · 10 comments
Closed

AddCaller hook can't be wrapped #40

akshayjshah opened this issue May 4, 2016 · 10 comments
Assignees
Labels

Comments

@akshayjshah
Copy link
Contributor

As currently implemented, the AddCaller hook doesn't work when wrapped (e.g., by Standardize) - we're hard-coding the number of stack frames to skip when finding the caller.

@justyntemme
Copy link

justyntemme commented May 16, 2016

Could this be fixed by adding an oop style setSkip function? Then just make sure to call setSkip before calling AddCaller.

@akshayjshah
Copy link
Contributor Author

That's more or less what I had in mind. I'd planned to add an IncCallerSkip option and have the zwrap constructors automatically pass the right values.

Are you thinking of opening a PR? 😍

@justyntemme
Copy link

Just issued a pr to fix this part way. Now we should just have to change the calls to addcaller.

@akshayjshah akshayjshah added this to the Release 1.0 milestone May 25, 2016
@akshayjshah
Copy link
Contributor Author

This is a near-duplicate of #83 - they're the same root cause, and should be fixed together.

@mranney
Copy link

mranney commented Aug 24, 2016

Any progress on this?

@akshayjshah akshayjshah removed this from the 1.0.0 milestone Sep 17, 2016
@akshayjshah
Copy link
Contributor Author

Not really, unfortunately.

The core problem here is that the approach we've taken is fast, but fragile - each logger needs to know exactly how many frames to skip. We can extend this approach to let CheckedMessage and wrapper types increment/decrement the skip count, but this gets pretty fiddly pretty fast.

I'd like to finish the other 1.0-related features, then see if there's a clean way to fix this problem. If there isn't, I'd like to remove the AddCaller hook until we're come up with a fast, clean implementation.

@rogpeppe
Copy link

We have this issue, as we are wrapping many our logging calls in a function that obtains the logger from a context value.

Letting CheckedMessage change the skip count would seem a reasonable solution to me, given that that type is explicitly intended for log wrapper use.

Perhaps CheckedMessage.Write method could take a "callDepth" count to let it know what the depth count is (as log.Logger.Output does). Or add a new method (WriteWithCallDepth ?) if backward compatibility is desired. I'm thinking that the method name doesn't need to be that short because it won't be used in many places.

@jcorbin
Copy link
Contributor

jcorbin commented Dec 23, 2016

Noting that some progress was attempted in the abandoned #183, and that #201 moves forward on this: the global _callerSkip is being dropped in lieu of a new logger.callerSkip field. Going forward we can do either or both of:

  • add fields to allow varying skip on a per log site basis (or even opting in to caller without doing it for all log sites)
  • add an option to change logger.callerSkip (e.g. zap.AddCallerSkip(int))
  • further make any / that option more useful by allowing it to be changed for sub loggers (e.g. the zap.Logger.WithOptions proposal)

@jcorbin
Copy link
Contributor

jcorbin commented Jan 11, 2017

Updating context: after #227 on dev, the only remaining piece changing skip on an existing logger after creating it. Whatever the mechanism of change is (type casting, with-options, or else) there is no more global skip value on dev.

akshayjshah pushed a commit that referenced this issue Feb 3, 2017
`zapcore.Facility` is the extension point we're offering to third-party
developers, so there's no need to make the logger an interface. In fact, an
interface will be *more* constraining, since we won't be able to add any methods
after version 1.0.

Along the way, this fixes our woes with `AddCaller` not working properly (#40).
akshayjshah added a commit that referenced this issue Feb 3, 2017
`zapcore.Facility` is the extension point we're offering to third-party
developers, so there's no need to make the logger an interface. In fact, an
interface will be *more* constraining, since we won't be able to add any methods
after version 1.0.

Along the way, this fixes our woes with `AddCaller` not working properly (#40).
@akshayjshah
Copy link
Contributor Author

The last part of the fix for this just landed on dev. Woohoo!

akshayjshah added a commit that referenced this issue Feb 15, 2017
`zapcore.Facility` is the extension point we're offering to third-party
developers, so there's no need to make the logger an interface. In fact, an
interface will be *more* constraining, since we won't be able to add any methods
after version 1.0.

Along the way, this fixes our woes with `AddCaller` not working properly (#40).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants