-
Notifications
You must be signed in to change notification settings - Fork 17
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
Why does log commands return error? #114
Comments
Hi @gucio321 It is true that many people feel uncomfortable with the log command returning an error. Without checking for errors, users cannot be assured that the log of an important failure has been successfully written to stdout, stderr, or any other write destination. Using the modification you suggested, if a log error occurs between glg.Infof and glg.Err in other goroutine threads, it will be difficult to ensure the consistency of the log, and will cause more complexity for the user than if the error returns from the Function Call implementation. |
Thanks for your answer! glg.SetErrorCallback(func(err error) {panic(err)}) The panic could be a default callback and user could change it |
I think that idea seems to work, but if we implement it and rewrite the current Interface, it would require a v2 release. |
Yah, In my project I'm using a kind of abstraction from the logging library, like this:
|
I see. |
No problem, |
Feel the contribution made by the big guy, this is indeed a good log library, may I ask this change about the error callback has online time? |
Hi there,
The logger is awesome ;-)
The only fact, i'm quit dissapointed is that the log commands return errors...
It seems a bit strange for me, since loggers are designed to handle errors, not produce them 😄
This is a bit annoying for me, since GoLand complains about "unhandled error"
What about changing API to something like:
The text was updated successfully, but these errors were encountered: