Closed planetoryd closed 5 months ago
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 rtnetlink
doesn't include anything meaningful in the returned error. I guess many other libraries could be doing that too, since bad practices are not banned (if you think thats bad).
since bad practices are not banned (if you think thats bad).
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 rtnetlink
does logging is the sort of place I'd say is reasonable to log in a library. It looks like a sort of long-running process? They may be better off keeping all their messages as trace
, but depending on the destination you're logging to you may be able to either filter out messages from the rtnetlink
crate entirely.
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.