Add option to include tracing spans in anyhow errors. #397
+226
−18
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wondering about thoughts adding optional support for capturing
tracing::Span
s in anyhow errors, very similar tobacktrace
s.The motivation behind this is that spans have the ability to provide lots of context for all log messages by themselves, however bubbling up an error to print loses a lot of this context, so I often find myself duplicating a lot of this "context adding" effort when using anyhow in conjunction, and still missing things that could be nice to have in an error message. It never feels great to have to use the
.with_context(|| format!(...))
pattern.There are some options, like logging errors "on site" in some deeply nested function rather than bubbling, but generally I tend to want to return some kind of message to a high level function when something went wrong before changing some flow, letting it decide the severity and print with an appropriate level, which is not possible with on-site logging. It's easy to filter spans out by level, target to reduce verbosity as well.
By having a span attached to this error, we can briefly enter it, print the error, and exit the span at some higher level function. This allows log messages to be printed as if they happened on site for "free".
The tracing-error crate does a lot of this, but it seems more geared toward printing a multi line trace, and does not provide the option to access spans within its
SpanTrace
type, forcing you to write your own visitor to change the way it is printed, and I don't find that it'sTracedError
type plays well with anyhow errors.I basically duplicated most of the internal macros/machinery that goes with capturing backtraces like hiding the functionality behind a feature flag and capturing the span at the "lowest" point only. Spans themselves being just identifiers makes them small, and the side effect of keeping the span branch in the tracing subscriber registry alive during the bubbling process is pretty small, since errors are generally short lived anyway.
If this seems like a good fit, I am happy to write the appropriate tests and any other requests.
Here is some example output using a contrived, overly logged anyhow_tracing_example.zip:
no tracing, debug
no tracing, info
no tracing, warn
tracing, debug
tracing, info
tracing, warn