-
Notifications
You must be signed in to change notification settings - Fork 168
BM-1577: standardize anyhow error formatting #1110
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The recommended idiomatic approach for
thiserroris to not include any{0}etc in the message when#[from]is used, and instead use:#or chaining methods when the final error is logged or printed.Otherwise, when the error message is unrolled automatically, this will result in very strange and long output. An example of this would be a
mainthat returns anAnyhow::Error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is specifically not what we want, because in that case the error would be multiline and hard to grep for and find with alerts. Perhaps I'm missing what you're saying, and I get that we may not be following idiomatic patterns exactly, but this seems ideal for what we actually want.
Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=79f43464fdc64fbaa098fa32f2a85b97
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The recommended and idiomatic way here would be
This then creates an error chain that can be followed to print the correct error message or to downcast the error, when an underlying type is needed.
One shortcoming of Rust in this regard is that println!("{:#}", ClientError::TxnConfirmationError(...)) does not always print the error chain in one line. Therefore, when the final outer error is printed, it must be wrapped in an
anyhow(usually automatic since ananyhow::Resultis usually returned) or aDisplayimplementation must be used that follows the chain must be used.Using
#[error("Transaction confirmation error: {0:#}")]will lead to incorrect output when something follows the error chain to print the message. This can happen withanyhowor other things, such as logging frameworks.See this example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=2ae4ba562c19bd0ed1c7224920c9e43a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without 'from' or 'source' would also work, as this error never creates a chain. However, you would lose features that rely on the canonical std::error::Error chaining.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, I am absolutely fine with the proposed changes if they are the easiest way to obtain usable log messages at this stage. I just wanted to point out that this is not recommended and could backfire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, just for expedience rather than switching all error printing to be
{:#}and removing the#[from]errors printing semantics. This PR is the most minimal change. If approved, I will open up an issue to switch it to be handled correctly in the future, where the:#formatting is not applied on the error type but on all the logs.The worst case here is that an error context is printed twice if the error is printed with
:#which is much less bad than error context not being included in the log for the time being (imo).