-
Notifications
You must be signed in to change notification settings - Fork 741
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
Value
implementation for dyn Error + 'static
prints first cause only
#1347
Comments
The issue here is in the default field formatter implementation for tracing/tracing-subscriber/src/fmt/format/mod.rs Lines 747 to 748 in 1e09e50
we see that only the immediate source is formatted, and any subsequent sources are skipped. We could fix this pretty easily by changing that code to format the whole source chain. We should probably also change the delimiters for the source so that they match the way other fields are formatted. Right now, a macro invocation like tracing::info!(foo = "some field", err = error.as_ref()); will be formatted like
which is not consistent with how other fields are formatted. We probably want something more like
or, when there are multiple sources, maybe
If we also want to change the behavior of the JSON formatter to emit error sources as a JSON list, we could add a
|
According to the format suggested in tokio-rs#1347 (comment)
According to the format suggested in tokio-rs#1347 (comment) Fixes tokio-rs#1347
## Motivation Fixes #1347 ## Solution Change the format from `err=message, err: source1` to `err=message err.sources=[source1, source2, source3, ...]`, as suggested in #1347 (comment) (still leaving out the sources if there are none). ## Caveats Haven't changed the JSON formatter, since I'm not really sure about how to do that. The current format is `{.., "fields": {.., "err": "message"}}`, disregarding the sources entirely. We could change that to `{.., "fields": {.., "err": "message", "err.sources": ["source1", "source2", "source3", ..]}}`, which would keep backwards compatibility but looks pretty ugly. Another option would be `{.., "fields": {.., "err": {"message": "message", "sources": ["source1", "source2", "source3", ..]}}}` which leaves room for future expansion. Then again, that begs the question about why the first error is special, so maybe it ought to be `{.., "fields": {.., "err": {"message": "message", "source": {"message": "source1", "source": ..}}}}`. But that style of linked list is pretty annoying to parse, so maybe it ought to be flattened to `{.., "fields": {.., "err": [{"message": "message"}, {"message": "source1"}, ..]}}`? Co-authored-by: Eliza Weisman <[email protected]>
Feature Request
When logging a
&std::error::Error
directly, only the first.source()
is printed, as seen in the example. This should be changed to log all of them instead.Crates
Likely
tracing
, if changing thetracing::Value
implementation.Motivation
It's pretty common to have errors that are fairly nondescript until one follows more than step up the source chain, so it would be good to have the underlying causes logged.
Proposal
Alternatives
Implement your own newtype wrapper with a
Display
impl.Somewhat related: #1308
The text was updated successfully, but these errors were encountered: