-
Notifications
You must be signed in to change notification settings - Fork 258
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
Important messages are not necessarily Errors #559
Comments
The level of a log event is really relative to the context it’s produced in. In general, I‘d discourage most libraries from logging at all unless they’re particularly stateful. In my experience, any that’s there tends to be filtered out by end-user applications in favour of more semantic events surrounding their integration points anyways. For the case of errors I think there’s really no need for a library to both return an error as well as log it, since that erroneous condition is already observable through the error return value. |
In my case the |
TL;DR: Just avoid using crates with bad practices. Unfortunately there's just no way to ban this behaviour easily. You can use a capability based system where even printing and logging is capsulated as a value implementing a trait (which itself is easy to do) but then you would have to explicitly pass them to every function. This over-explicit way of passing cap would be fixed by the capability proposal in rust https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capabilities/ But AFAIK it's still in pre-RFC stage, so you would have to wait for quite some time until that is there. Even with cap, not every crate would support it. |
It looks like the case where |
chore: Release Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Jiahao XU <Jiahao_XU@outlook.com>
After nearly a year of no activity I'm closing this. Feel free to reopen if more needs to be discussed. |
I came across a situation where, a dependency logs in Errors, but my app can handle the Errors and still succeed in the task.
It just feels too weird to log Successes as Errors, like having some cognitive dissonance
If a user sets the logging level to
Error
, he will only see the Error messages by the dependency while the success messages are logged in Info (they aren't errors), and get confused.The text was updated successfully, but these errors were encountered: