Add ability to print error Result using err via Debug instead of only Display
#1630
Comments
Syntactically, what do you think about using |
|
Hmm, But I am not sure if I understood |
|
hi @hawkw , I have implemented As an alternative, how would you regard |
|
Another idea: |
The I think it would be good to support this as well, but it's only applicable when the error type being returned implements the |
|
Oh, see now. I also understand why we would need to specify Is it ok, if we cover this later, in a separate issue/PR? I'd be willing to implement this as well. |
Yeah, that's right! Sorry if that wasn't clear from my original comment!
Of course. I think this should definitely be a follow-up change once the |
## Motivation This PR attempts to solve #1630 by introducing `err(Debug)` meta to `intrument` attribute macro. As `err` meta causes the error (`e`) returned by instrumented function to be passed to `tracing::error!(error = %e)` i.e. makes it use the `Display` implementation of `e`, the newly added `err(Debug)` makes expands to `tracing::error!(error = ?e)` which makes the `error!` macro to use `Debug` implementation for `e`. `err` and `err(Debug)` are mutually exclusive, adding both will create a compilation error. `err(Display)` is also supported to specify `Display` explicitly. As tried to describe, for some types implementing `Error` it might be more suitable to use `Debug` implementation as in the case of `eyre::Result`. This frees us to manually go over the error chain and print them all, so that `instrument` attribute macro would do it for us. ## Solution - Added a custom keyword `err(Debug)` similar to `err`, - Add `err(Debug)` field to `InstrumentArgs`, - Add parsing for `err(Debug)` arg and check for conflicts with `err`, - Generate `tracing::error!(error = ?e)` when `err(Debug)` is `true` and `tracing::error!(error = %e)` when `err(Display)` or `err` is `true`, - Interpolate generated `err_block` into `Err` branches in both async and sync return positions, if `err` or `err(Debug)` is `true`.
|
Closed by #1631! |
## Motivation This PR attempts to solve #1630 by introducing `err(Debug)` meta to `intrument` attribute macro. As `err` meta causes the error (`e`) returned by instrumented function to be passed to `tracing::error!(error = %e)` i.e. makes it use the `Display` implementation of `e`, the newly added `err(Debug)` makes expands to `tracing::error!(error = ?e)` which makes the `error!` macro to use `Debug` implementation for `e`. `err` and `err(Debug)` are mutually exclusive, adding both will create a compilation error. `err(Display)` is also supported to specify `Display` explicitly. As tried to describe, for some types implementing `Error` it might be more suitable to use `Debug` implementation as in the case of `eyre::Result`. This frees us to manually go over the error chain and print them all, so that `instrument` attribute macro would do it for us. ## Solution - Added a custom keyword `err(Debug)` similar to `err`, - Add `err(Debug)` field to `InstrumentArgs`, - Add parsing for `err(Debug)` arg and check for conflicts with `err`, - Generate `tracing::error!(error = ?e)` when `err(Debug)` is `true` and `tracing::error!(error = %e)` when `err(Display)` or `err` is `true`, - Interpolate generated `err_block` into `Err` branches in both async and sync return positions, if `err` or `err(Debug)` is `true`.
## Motivation This PR attempts to solve #1630 by introducing `err(Debug)` meta to `intrument` attribute macro. As `err` meta causes the error (`e`) returned by instrumented function to be passed to `tracing::error!(error = %e)` i.e. makes it use the `Display` implementation of `e`, the newly added `err(Debug)` makes expands to `tracing::error!(error = ?e)` which makes the `error!` macro to use `Debug` implementation for `e`. `err` and `err(Debug)` are mutually exclusive, adding both will create a compilation error. `err(Display)` is also supported to specify `Display` explicitly. As tried to describe, for some types implementing `Error` it might be more suitable to use `Debug` implementation as in the case of `eyre::Result`. This frees us to manually go over the error chain and print them all, so that `instrument` attribute macro would do it for us. ## Solution - Added a custom keyword `err(Debug)` similar to `err`, - Add `err(Debug)` field to `InstrumentArgs`, - Add parsing for `err(Debug)` arg and check for conflicts with `err`, - Generate `tracing::error!(error = ?e)` when `err(Debug)` is `true` and `tracing::error!(error = %e)` when `err(Display)` or `err` is `true`, - Interpolate generated `err_block` into `Err` branches in both async and sync return positions, if `err` or `err(Debug)` is `true`.
Feature Request
Crates
Motivation
Currently
instrumentattribute macro'serrmeta item makes the expanded code to print theErrresult only using itsDisplayimplementation. SomeErrortypes could be more beneficial to be printed using theirDebugimplementation. For exampleeyre::Resultcontains an error chain. When printed in viaDisplay, it shows the most recent error message. But if you print it via theDebugimplementation it shows the error with the error chain.Proposal
Being able to write
#[insturment(?err, ...)]would be in line withtrace!et. al macro's fields, but it appears this isn't compatible with meta item syntax. Maybe two alternatives can be provided as:#[instrument(err, ...)]: print theErrorusingDisplayimplementation so that existing codes aren't affected.#[instrument(err_dbg, ...)]: print theErrorusingDebugimplementation.I am willing to work on this and open a PR. Let me know if you can think of a better alternative syntax.
Alternatives
The only alternative I can think of is to remove
errmeta item from the attribute, catch the error somehow and print manually with"{:?}"format string. But this defeats the purpose of#[instrument]attribute (ergonomy) as it could easily implement this behavior.The text was updated successfully, but these errors were encountered: