Add new error handling blog post #799
Conversation
yaahc
commented
Mar 16, 2021
•
yaahc
commented
- Rendered
|
r? @rust-lang/libs as well |
posts/inside-rust/2021-03-15-What-the-error-handling-project-group-is-working-towards.md
Outdated
Show resolved
Hide resolved
…roup-is-working-towards.md Co-authored-by: oliver <[email protected]>
posts/inside-rust/2021-03-15-What-the-error-handling-project-group-is-working-towards.md
Show resolved
Hide resolved
posts/inside-rust/2021-03-15-What-the-error-handling-project-group-is-working-towards.md
Outdated
Show resolved
Hide resolved
…roup-is-working-towards.md Co-authored-by: Mara Bos <[email protected]>
|
|
||
| So we need some way to create panics _from_ `Error` types that doesn't hide the `Error` interface. We'd like it if `PanicInfo` could store a `dyn Error + 'static` instead of, or in addition to the `dyn Any + 'static` payload it currently carries. We're thinking about adding a `std::panic::panic_error` function similar to `std::panic::panic_any`. Then, if possible, we'd like to specialize the `unwrap` and `expect` functions on `Result` to call `panic_error` instead of `panic!` when `E` implements `Error`. | ||
|
|
||
| We're not sure this is possible but either way we will figure out some way to integrate the two error handling systems more smoothly, though first we have to move the `Error` trait into `core`. :eyes: |
There was a problem hiding this comment.
Can this link to a document with more information about what the current status/blockers are for moving Error into core?
|
|
||
| These `From` impls interfere with our `Error` impl due to the "Overlap Rule", which states that no two generic implementations of a Trait can apply to the same type. If `Box<dyn Error>` implements the `Error` trait both of the `From` impls above would apply, and `BoxError::from(other_box_error)` becomes ambiguous. The compiler doesn't know whether it should pass the Box through directly or wrap it in another `Box`. | ||
|
|
||
| In theory we could fix this in the future if we ever get specialization finished, but as far as we know its highly unlikely that it would be useful in this specific case. We'd need to support [lattice specialization](https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md#the-lattice-rule) which is, by our most optimistic understanding, very far from happening if ever. |
There was a problem hiding this comment.
This paragraph starts a bit too optimistically given how it ends; "in theory we could fix this" implies hope, but it seems to me it should read something more like "even in our wildest dreams this probably won't be fixed by specialization".
|
|
||
| In theory we could fix this in the future if we ever get specialization finished, but as far as we know its highly unlikely that it would be useful in this specific case. We'd need to support [lattice specialization](https://github.com/rust-lang/rfcs/blob/master/text/1210-impl-specialization.md#the-lattice-rule) which is, by our most optimistic understanding, very far from happening if ever. | ||
|
|
||
| ### Hope, AKA `Try` trait v2 RFC |
There was a problem hiding this comment.
Now that this RFC is in its final revision, just wanted to confirm that everything in this document is still true (bikeshedded names notwithstanding).
|
|
||
| To summarize on the above our plan is to: | ||
|
|
||
| 1. Move the error trait into core |
There was a problem hiding this comment.
This comes a bit out of nowhere considering this is the first item on the plan. There was no other mention of core in the rest of the blog post.
|
|
||
| ## Guidelines for implementing `Display::fmt` and `Error::source` | ||
|
|
||
| But before we get into the plans we first need to share an announcement. Project Error Handling recently created a guideline for [how to implement `Display::fmt` and `Error::source`](https://github.com/rust-lang/project-error-handling/issues/27#issuecomment-763950178). To create this guideline we first had to answer a fundamental question, _What is the primary role of the error trait?_. |
There was a problem hiding this comment.
That renders funny with the period following the questionmark.
|
|
||
| If we decide to prefer the latter then we would want to prioritize exposing every error type in the chain of errors to ensure users can always correctly downcast to specific error variants they want to handle. In this situation the guidance would be: _Always return source errors via `Error::source`._ | ||
|
|
||
| After some discussion we concluded that the reporting focused viewpoint was the ideal one. We prefer splitting our errors into multiple error messages with no duplication of information as opposed to having each error print itself followed by all others. This split moves the responsibility of formatting to the end user, rather than relying on many library authors concatenating error messages together with a consistent format. |
There was a problem hiding this comment.
Why is this is considered the "ideal" approach? It feels as if the mission of the "The Error Handling Project Group" was to prioritise the presentation of errors rather than the handling of errors (as indicated in the project group name). For a systems programming language I feel that the handling of errors should have priority over the presentation of errors; there're systems which do not even have the ability to present error messages to a user (e.g. embedded devices) but where error handling is of utmost importance (and rather poorly supported by Rust at the moment).
There was a problem hiding this comment.
Why is this considered the "ideal" approach?
Perhaps ideal isn't the best vocab here, since there isn't really a right answer. The reasoning is that we evaluated the trade-offs and costs of the various options and found that this was the least bad option, given that it doesn't prevent reacting to source errors via downcasting, where-as the alternative completely prevents configurable and consistent error reporting formats by duplicating information throughout the Error interface. If you're interested in a more in-depth analysis of the trade offs and why we felt it was best to prioritize deduplicating information please checkout this issue: rust-lang/project-error-handling#27
It feels as if the mission of the "The Error Handling Project Group" was to prioritise the presentation of errors rather than the handling of errors (as indicated in the project group name). For a systems programming language I feel that the handling of errors should have priority over the presentation of errors; there're systems which do not even have the ability to present error messages to a user (e.g. embedded devices) but where error handling is of utmost importance (and rather poorly supported by Rust at the moment).
"Error Handling" a superset of responsibilities, which in my mind includes creating, propagating, matching/reacting, discarding, and reporting. This is more accurately a tension between how you can programmatically react to specific errors and how you represent and report them, as opposed to handling in general. I think its well within the mission of the error handling project group to analyze the trade offs and make a recommendation one direction or the other.
There was a problem hiding this comment.
Hmm, @yaahc, I'd love to discuss this post a bit over voice sometime. To be quite honest, reading it, I had a hard time following it. I'd like to get a better idea of who the audience is and what the top-level goals are that you're trying to communicate. It might be that it wants to be structured into a few separate posts, even.
|
I'm closing this PR for now because I'm working on rewriting this blog post based on the feedback I received from @nikomatsakis. I'll do my best to include all the feedback given in the updated version of the blog post where applicable. |
