-
Notifications
You must be signed in to change notification settings - Fork 734
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
Ergonomic Reporting of std::error::Error #1308
Comments
A related issue is this is only implemented for As an example of where this is annoying, if I have an |
|
The |
Ahh right, downcasting relies on |
Right, this is also why the standard library deprecated |
`Value` was already implemented for `dyn Error + 'static`, but rust doesn't silently coerce trait objects. This means that passing an error of type `dyn Error + Send + Sync + 'static` would not work. These extra impls just delegate to the existing `dyn Error + 'static` impl. Also update one of the examples to use `dyn Error + Send + Sync` to demonstrate that this works. Refs: tokio-rs#1308
`Value` was already implemented for `dyn Error + 'static`, but rust doesn't silently coerce trait objects. This means that passing an error of type `dyn Error + Send + Sync + 'static` would not work. These extra impls just delegate to the existing `dyn Error + 'static` impl. Also update one of the examples to use `dyn Error + Send + Sync` to demonstrate that this works. Refs: tokio-rs#1308
`Value` was already implemented for `dyn Error + 'static`, but rust doesn't silently coerce trait objects. This means that passing an error of type `dyn Error + Send + Sync + 'static` would not work. These extra impls just delegate to the existing `dyn Error + 'static` impl. Also update one of the examples to use `dyn Error + Send + Sync` to demonstrate that this works. Refs: tokio-rs#1308
## Motivation `Value` was already implemented for `dyn Error + 'static`, but rust doesn't silently coerce trait objects. This means that passing an error of type `dyn Error + Send + Sync + 'static` would not work. This is related to #1308. ## Solution Add impls for `dyn Error + …` variants for `Send`, `Sync`, and `Send + Sync`. These extra impls just delegate to the existing `dyn Error + 'static` impl. Also update one of the examples to use `dyn Error + Send + Sync` to demonstrate that this works. Refs: #1308
## Motivation `Value` was already implemented for `dyn Error + 'static`, but rust doesn't silently coerce trait objects. This means that passing an error of type `dyn Error + Send + Sync + 'static` would not work. This is related to #1308. ## Solution Add impls for `dyn Error + …` variants for `Send`, `Sync`, and `Send + Sync`. These extra impls just delegate to the existing `dyn Error + 'static` impl. Also update one of the examples to use `dyn Error + Send + Sync` to demonstrate that this works. Refs: #1308
Apart from this not being ergonomic (yet), the problem is also that the Rust compiler errors are not really helpful in this case. A more prominent example that shows users how to do it would be a really good idea. We have too many cases in our codebase where we just use the It might be a good idea to explicitly call out in the docs, How to capture a The only example in the main crate docs is hidden under the For |
## Motivation Currently, the tracing instrumentation macro emits a single event after the function call, but in the current span, with just a field named error set. For example: ```rust #[instrument(err)] fn test() -> Result<(), ()> { ...body } ``` gets roughly expanded to ```rust fn test() -> Result<(), ()> { let span = span!("test") fn inner() -> Result<(), ()> { ...body } match inner() { Ok(x) => Ok(x), Err(err) => { error!(error=%err) Err(err) } } ``` In the error case of the result, the macro will emit an error level event with just an `error` field set to the display (or debug) value of the returned error. While there exists support for the Error primitive in tracing, the primitive only supports 'static Errors. See tokio-rs/tracing#1308 ## Solution This PR adds support to use this event to fill the span status error description with the content of the error field of this event. Additionally, this ass support to emit these events (or manually created ones that follow the same format) as OTel events following the exception convention. The operation is optional and can be configured using the `ErrorFieldConfig`. This seems like another hack similar to `otel.*` fields, but should reduce some boilerplate in existing codebases. I propose to keep this until `tracing` improves support for Error fields.
This commit adds a `Value` implementation for `Box<T> where T: Value`. This is *primarily* intended to make `Box<dyn Error + ...>` implement `Value`, building on the `Value` impls for `dyn Error + ...` added in tokio-rs#2066, but it may be useful for other boxed values as well. Refs: tokio-rs#1308
Feature Request
Find some more ergonomic way to report
std::error::Error
values.Crates
tracing
Motivation
Logging a type that implements
std::error::Error
is currently quite awkward.Value
is only implemented fordyn std::error::Error
.That means logging a concrete type involves awkward type gymanstics for something that is a very common operation.
(unless I'm missing some trick here...)
EG:
Proposal
Not sure what would be the best way to implement this.
A generic default
impl
is probably out of the question without specialization.The most straight-forward solution would probably be a new formatter sigil, eg
!
.The text was updated successfully, but these errors were encountered: