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

Inherent design problem with HandleLog function #62

Open
tympanix opened this issue Jun 26, 2018 · 3 comments
Open

Inherent design problem with HandleLog function #62

tympanix opened this issue Jun 26, 2018 · 3 comments

Comments

@tympanix
Copy link

Problem:
It is allowed by the developer to construct a Entry struct (field are public), but you supply no way to submit the entry to a handler correctly using the HandleLog function.

How?
The Entry struct requires to be finalized, which can only be obtained using the private, which is only called here:

log/logger.go

Line 146 in ff0f669

if err := l.Handler.HandleLog(e.finalize(level, msg)); err != nil {
This leaves the developer forced to use the public methods of the Logger struct, which does not support the HandleLog function

Why?
Sometimes the developer may want to have complete control of the logging (e.g. setting the log level of the entry dynamically)

Possible solutions:

  • Make the finalize function public
  • Wrap all HandleLog functions and call finalize beforehand
  • Add HandleLog to the Logger struct and call finalize
  • Create a wrapper handler which only job is to finalize the entry

You are probably more suited to find a proper solution yourself. Your thoughts?

@tympanix tympanix changed the title Inherent design problem Inherent design problem with HandleLog function Jun 26, 2018
@tj
Copy link
Member

tj commented Jun 26, 2018

Hmmm tough call, I feel like exposing .finalize would be a little gross, but I see what you mean. I think the part I dislike the most right now is that Entry.Logger, it would be nice if we could just pass an Entry to the handler without any reference to that

@tympanix
Copy link
Author

I agree. Finalizing the Entry should be transparent to the developer. But with no gab between the actual Entry and the HandleLog function, figuring out a solution is tricky. Could we possibly do without a finalize method at all? The developer will be responsible for settings the timestamp on the Entry themselves (this would of course still be handled in the higher level functions Info, Warn Error etc.)

@tj
Copy link
Member

tj commented Jun 29, 2018

Yeah I think that would be fine, I can't remember why I did it this way haha, maybe just a convenience thing but I'm down with that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants