-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
Could this be fixed by adding an oop style setSkip function? Then just make sure to call setSkip before calling AddCaller. |
That's more or less what I had in mind. I'd planned to add an Are you thinking of opening a PR? 😍 |
Just issued a pr to fix this part way. Now we should just have to change the calls to addcaller. |
This is a near-duplicate of #83 - they're the same root cause, and should be fixed together. |
Any progress on this? |
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 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 |
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. |
Noting that some progress was attempted in the abandoned #183, and that #201 moves forward on this: the global
|
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. |
`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).
`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).
The last part of the fix for this just landed on dev. Woohoo! |
`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).
As currently implemented, the
AddCaller
hook doesn't work when wrapped (e.g., byStandardize
) - we're hard-coding the number of stack frames to skip when finding the caller.The text was updated successfully, but these errors were encountered: