-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Wrapping into the standard logger #7
Comments
passing a writer to SetOutput will make some strange beast. For example, it will add all I think the wrapper should be from the opposite side, but such wrapper probably impossible to do because ErrorLog is not an interface. |
You are right that there is no good solution. We can do something that is better than nothing only. Note that I don't propose to implement general solution but the specific solution for use with
When creating an instance of // It is assumed that the returned logger will not be further adjusted
// (i.e. (*Logger).SetOutput() method will not be called).
func (*Logger) ToStd(prefix, callerInfo string) *log.Logger {} If you think that we should leave |
I don't have a strong opinion on this one. The use case is narrow and even exotic, but probably worth to be covered. I see why we want to pass prefix (probably can be optional and defaulted to WARN) but not so sure about callerInfo for the same reason discussed in #8 |
I have added a pair of trivial wrappers for |
The problem
There is a field
ErrorLog *log.Logger
in Go'shttp.Server
. From docs: "ErrorLog specifies an optional logger for errors accepting connections, unexpected behavior from handlers, and underlying FileSystem errors. If nil, logging is done via the log package's standard logger."Example code that triggers logging:
If we run above server and issue this command:
then the server prints this error message:
Propose
Maybe it makes sense to implement
lgr.Logger
wrapping into the standard logger.Thoughts about implementation
Basically the only thing we need to implement is a custom
io.Writer
. Then we can pass it to thelog.Logger
's constructor or set it up viaSetOutput()
function or method. But some problems arise if we do caller logging. Even if we skip all call frames related tolog
package then we still be somewhere insidenet/http
package. If we skip more frames then we may end up in our code (unexpected behavior from handlers, as in example) but may be not (errors accepting connections, FileSystem errors). So it may be worth to log only some generic caller info like{net/http}
. This info may be passed as an argument to a method/function that wrapslgr.Logger
.The text was updated successfully, but these errors were encountered: