-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Establish a new error handling project group #2965
Conversation
text/0000-project-error-handling.md
Outdated
- Provide a derive macro for `Error` in std. | ||
- Stabilize the `Backtrace` type but possibly not `fn backtrace` on the Error trait. | ||
- Provide necessary API on `Backtrace` to support crates like `color-backtrace`. | ||
- Move error to core . |
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.
related: rust-lang/rust#72981 (comment)
As noted in https://internals.rust-lang.org/t/idea-fixed-sized-traits/12179/8 we could define a |
You should put a "rendered" link in the first post |
text/0000-project-error-handling.md
Outdated
Here is a tenative starting point, subject to change: | ||
|
||
- Use `Result` and `Error` types for recoverable errors. | ||
- Use `panic` for unrecoverable errors. |
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.
Do you want to touch unwind
? I am asking, because that is for no_std
and async
poorly documented
and let to some confusion here.
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.
I'm not particularly well informed on the implementation details of unwinding but I can see it being within the purview of this project group.
Tagging with T-lang and T-libs, though I have to review the plans to tell how much the lang applies. =) |
Co-authored-by: Jake Goulding <shepmaster@mac.com>
OK, I've read in more detail, and I guess that the scope of this is pretty limited to library API development, so I've removed T-lang. =) |
text/0000-project-error-handling.md
Outdated
@@ -43,6 +43,13 @@ Here is a tenative starting point, subject to change: | |||
- What is the consensus on handling `dyn Error`s? Should it be encouraged or discouraged? Should we look into making `Box<dyn Error...>` implement `Error`? | |||
|
|||
|
|||
### Identify pain points in error handling today | |||
|
|||
- Backtrace capture is expensive, but without one it can be difficult to pinpoint the origin of errors |
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.
- Backtrace capture is expensive, but without one it can be difficult to pinpoint the origin of errors | |
- Backtrace capture is expensive, but without it can be difficult to pinpoint the origin of errors |
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.
I generally disagree with the universal applicability of this point as well; this is a key point of SNAFU — producing a semantic backtrace via the error types.
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.
Assuming I understand what you mean, I think that the semantic backtraces via SNAFU
can definitely help here but I don't think they're a universal solution. It still fairly easy to misuse. For example, if a developer introduces a higher level snafu error to handle an io::Error
, but then uses this type liberally throughout the code. Unless you carefully create one variant per source location the origin of errors can still be lost.
Here's an example of this kind of thing going wrong via thiserror
. ZcashFoundation/zebra#758
text/0000-project-error-handling.md
Outdated
|
||
- Backtrace capture is expensive, but without one it can be difficult to pinpoint the origin of errors | ||
- unwrap on errors without first converting to a reporting type will often discard relevant information | ||
- errors printing from main have to assume a prefixed `Error: `, sub par control of output format when printing during termination. |
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.
- errors printing from main have to assume a prefixed `Error: `, sub par control of output format when printing during termination. | |
- errors printed from `main` have to assume a prefixed `Error: `, sub-par control of output format when printing during termination. |
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.
I don't know what "have to assume a prefixed Error:
" means.
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.
I'm referring to this default in std
's impl of Termination
for Result
https://doc.rust-lang.org/stable/src/std/process.rs.html#1690-1696, right now there's no way to signal to Debug
types that they're being formatted as part of Termination
or not. @dtolnay has suggested adding an is_termination
flag to Debug
. I'm also interested in the possibility of a 3rd std::fmt
trait called std::fmt::Report
to handle this and reporting in panic hooks, leveraging specialization for backwards compatibility.
text/0000-project-error-handling.md
Outdated
- Backtrace capture is expensive, but without one it can be difficult to pinpoint the origin of errors | ||
- unwrap on errors without first converting to a reporting type will often discard relevant information | ||
- errors printing from main have to assume a prefixed `Error: `, sub par control of output format when printing during termination. | ||
- Error trait only exposes 3 forms of context, can only represent singly linked lists for chains of errors |
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.
- Error trait only exposes 3 forms of context, can only represent singly linked lists for chains of errors | |
- The `Error` trait only exposes three forms of context, can only represent singly-linked lists for chains of errors |
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.
It's unclear what the pain points are here.
- Is three too many or not enough?
- Why is a singly-linked list painful?
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.
3 is not enough, I'd like to be able to return SpanTraces
, std::panic::Location
, and other such types via the error trait, this is a reference to the generic member access RFC.
Singly linked lists can be painful for parsers for example, where you encounter multiple errors at once, and they're all the source for a single higher level error, so your chain of errors looks a little more like a tree. This is also addressed by the generic member access proposal where you could access a dyn Iter<Item=&(dyn Error + 'static)>
.
Since it comes up whenever we talk about In general I don't think it would be fair to drop a works in EDIT: My bad! You've already got a section for it: https://github.com/yaahc/rfcs/blob/ehpg/text/0000-project-error-handling.md#consolidate-ecosystem-by-merging-best-practice-crates-into-std |
Team member @KodrAus has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
I'm on the library team, but not on the checkbox list because I can't keep up with FCPs on std, but would like to be involved in RFCs. So I guess consider my imaginary checkbox ticked. ping @SimonSapin @sfackler @withoutboats For checkboxes. People are eager to get started here. :-) |
Based on the current state of the Libs FCP list, I'll go ahead and check SimonSapin's box. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Coming a bit after the party but I think it's worth stating my concern: In my opinion no error should be unrecoverable for the user. Let me explain a bit further: there are mechanisms that allow you to do something in case of a I think the only case where a |
This seems like something that's best discussed as part of the project group, rather than the project group proposal. Once we have a repo setup though I'm happy to put this on the agenda of things to discuss. |
We're just about at the end of the FCP here so will be able to get started soon 🎉 What will the next steps be once we're ready to merge the RFC? I was thinking:
Does that sound right? As for how to do these things:
I'm super excited to get started on this! |
Same ^_^ |
Here’s a draft of an announcement post. Let me know what you all think! If I left out anyone’s name that
|
That looks great to me @seanchen1991! |
looks perfect @seanchen1991 |
Awesome! Not sure how things get posted to the Inside Rust blog. @KodrAus do you handle that part? |
@seanchen1991 You can submit a pull request here: https://github.com/rust-lang/blog.rust-lang.org/ I think your draft looks good enough to simply copy-and-paste into a new post under the "Inside Rust" folder. |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
Ah looks like I haven't got permission to merge this RFC manually, so for whoever comes along that is able to, the tracking issue is this one: rust-lang/libs-team#3 ❤️ |
Huzzah! The @rust-lang/libs team has decided to accept this RFC. To track further discussion, subscribe to the tracking issue here: |
I messed up the merge, but it's fixed in #2986! |
Rendered