Error Handling Project Group
Summary
A group focusing on Rust's error handling story. The group has the following high-level goals:
- Agree on and define common error handling terminology
- Come to a consensus on current best practices
- Identify pain points in error handling today
- Communicate current best practices
- Evaluate options for error reporting type a.k.a. better
Box<dyn Error> - Consolidate ecosystem by merging best practice crates into std
- Add missing features
Info
- Leads: @yaahc, @seanchen1991, @BurntSushi
- Libs-team liaison: @KodrAus
- Charter
- Repository rust-lang/project-error-handling
- Zulip stream
#project-error-handling
What is this issue?
This issue represents an active project group. It is meant to be used for the group to post updates to the libs team (and others) in a lightweight fashion. Please do not use the comments here for discussion, that should be kept in the Zulip stream (discussion comments here will be marked as off-topic).
Error Handling 2020-09-28 Meeting
https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/Meeting.2009-28-2020
Topic 1: Discussing stabilizing Backtrace
- Global hooks vs Boxing vs a trait-based approach for stabilizing
Backtraceincore. - Going with the trait-based impl for
Backtracein core.- Private trait + public newtype wrapper.
- Start with
eddyb's impl and see how many hooks are necessary along the way.
- private trait with a public newtype wrapper
- newtype wrapper is an interface not subject to coherence so we can add new methods without worrying about breaking changes downstream
- https://doc.rust-lang.org/stable/src/std/io/error.rs.html#67-71
- trait-based approaches have fewer magic compiler pieces and so would be easier to put together
write_backtrace_to(&mut dyn FormatterThing) -> Result<(),FormatterThing::Error>- ultimately about moving
Errorto core
- ultimately about moving
- should we do a trait object based solution internally with an unstable
Backtracetrait in core and a stableBacktracetype in core or should it use global hooks likepanic_impl - need a prototype solution for exposing
Backtraceas a type incorewith the interface it currently provides instd
Topic 2: What RFCs should this group be tracking?
- This group will have its own Project board to track relevant issues/RFCs.
- Prep status reports on relevant issues we're tracking for future meetings.
- Pulled from the tracking board
- #58520 tracking issue for error source iterators
Topic 3: Planning for "Communicating Best Practices"
- Facilitate communication of best practices via a Book/documentation.
- Should include some guidance on FFI error handling.
- Adding a book section to the project repo (using mdbook).
- Publish The Rust Error Book (name subject to change) and potentially contribute to The Book to make its error handling recommendations consistent with what this group decides.
Topic 4: What is the long-term vision of what error handling in Rust looks like?
Errorincore.- Stabilization of unstable
Errorinterfaces. - Iterator API on
Backtrace. - Generic member access (possibly with two-way flow).
- Error return traces.
- Some way to universally hook into all error reporting points for consistent error reporting.
- Better handling of error enums
- Guidance on FFI error handling.
- Ways of recovering from recoverable errors.
- enum-convergance as errors propagate up the stack
Error Handling 2020-10-12 Meeting
https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/Meeting.202020-10-12
Backtrace in core
- So far the implementation is moving forward fine, but there are questions around the hooks
- Not clear how to set them up with a default in
no_stdso users don't need to write one like#[panic_handler] - Current work in progress here
- There's enough sketched out that it shouldn't be a blocker for stabilizing
backtraceanymore
The Rust Error Book
- We now have a folder in the
project-error-handlingrepository for content
Log-term project group vision and goals
- Draft here: https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view
Generic member access RFC
- There's an updated API in
object-providerthat the RFC would like to use - Once the content is updated it needs some Libs input
- There could be some tie in with
tide'sResponsetype?
Fix the Error trait / Stabilizing backtrace
- Covered in the earlier discussion on Backtrace in core
- There could be some documentation work to do on
backtrace
Stabilizing Error source iterators
- stabilizing error source iterators
- trait objects vs. provided methods
- stabilization report 2020-09-14
- unergonomic use-cases ---> difficulties stabilizing
- bugs
- blocked on #53487
- #75180 might feed into this too
- related crate
error-chain
Stabilizing Error::type_id
- Several possible approaches, but all are waiting for other stabilizations/RFCs
- #[marker] trait stabilization: https://github.com/rust-lang/rust/issues/29864
- negative trait impls
- dynamic vtable type_id (like C++ typeid keyword) https://github.com/rust-lang/rfcs/pull/2580
- final keyword -> no overriding of trait any more
- new trait TypeInfo https://github.com/rust-lang/rfcs/pull/2738
- Not clear it's something we want to stabilize
- Looks like a rabbit hole we don't want to go down right now
PanicInfo::message
- No progress made here
Nicer Assert Messages
- RFC has been approved, with no implementation started yet
- Does this need to be implemented using the compiler's built-in proc macros, or can it be done as an external crate using
pro-macrosandsyn?- Need external thoughts/mentorship on this question
Iterating over Backtrace frames
- Just starting out, so there hasn't been much discussion yet
- The
backtracecrate has aframes()fn that already exposes its individual frames - We could propose basically the same thing for
std'sBacktracetype
Error Handling 2020-10-26 Meeting
https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/Meeting.202020-10-26
impl<'a, E: Error + Sized + 'a> Error for &'a E
- We believe we should pursue stabilizing this. There's already an open PR to update: https://github.com/rust-lang/rust/pull/75180
dyn Error or impl Error?
- We think the recommendation of
&(dyn Error + 'static)for borrowed abstract errors andimpl Error + Send + Sync + 'staticfor owned abstract errors is reasonable.
Table of contents for the Rust book
- We've sketched out a table of contents that's ready to PR back to the main repository.
Stabilization for Backtrace
- There's a current question about whether it's a problem that
Backtracedoesn't share much with the internal machinery used to print panic backtraces.- @KodrAus is looking into it, and will post an update on the stabilization PR.
- The panic implementation is a little different because it doesn't require all frames to be captured upfront, which is important for panic-on-oom support. Even if we don't share everything we should be able to share a little more between
sys_common::backtraceandbacktrace.
Fixing the Error
- The last outstanding item is that you can't use the precision flag to limit the number of frames being printed when formatting a backtrace. This doesn't need to block stabilization, and
Backtrace::framesshould also make it less important.
PanicInfo::message
- It's currently in progress.
Better assert RFC
- It's currently in progress.
Backtrace::frames
- There's an open PR for it that we're working through.
Vision blog post
- It's been updated with the latest round of feedback and is ready to go!
Error Handling 2020-11-09 Meeting
https://rust-lang.zulipchat.com/#narrow/stream/257204-project-error-handling/topic/Meeting.202020-11-09
Progress on Backtrace in Core [Jane Lusby]
- No progress on this since last time
Update Generic Member Access API [Jane Lusby]
- Reviewed changes made by Nika
- We should be using rustc errors as an example in the RFC
- Universal reporting is still messy and depends on features that don't exist yet
- RFC for this is basically complete with some pending updates including examples related to compiler error reporting
Adding an Error impl for &impl Error [Ashley Mannix]
- In final comment period. Will go in 1.49.0 when it's ready to go.
- starting patching for related libraries
Review the “Fix the error trait” tracking issue [Oliver + Ashley Mannix]
- No progress on this
Review the panic plan rfc [Jane Lusby]
- Now waiting for the FCP checkboxes; four more to go
Reach out to the author of the error codes issue [Jane Lusby]
- Didn't get to this
Post long term plan blog post [Sean Chean & Jane Lusby]
- Haven't put in suggested changes yet.
Begin writing chapters for The Rust Error Book [unassigned]
- Put out a call for a collection of references
- Are we targeting 2021 edition?
- Not particularly; shouldn't have any major breaking changes
- Besides unifying
panic, shouldn't have anything that interacts with editions - Universal error reporting might become something that involves requiring a breaking change, but too nebulous to know at the moment
Resolve blockers in the backtrace stabilizition PR [Ashley Mannix]
- Different implementions for panics and errors since the panic backtrace resolver can resolve frames in the presence of memory errors.
- Code between the two implementations can be shared, though this probably doesn't have implications on the API.
- Unlisted concern in FCP
- Blocked on Amanieu having time to look through the recent discussion to mark concern as resolved
Discuss universally consistent error reporting [Jane Lusby, Jakub Duchniewicz, and Jeremiah Senkpiel]
- Trying to find a way to introduce a "Reporter" that handles displaying
E: Errorobjects and additionally captures context relevant to those errors. - Maybe extend this type to also handle
PanicInfoobjects - Should naturally fit the design of the Error trait -PanicInfoalready has this handled by the hook fromset_hook- Unification will be a challenge
Backtrace Frames Method [Sean Chen]
- Started on this, though need to continue working through details from @KodrAus
- Suggestion to use a wrapper to return a borrow to data behind a
Mutex- @KodrAus -- for safety should materialize a
Vecbehind a wrapper - additional suggestions forthcoming
- @KodrAus -- for safety should materialize a
Nicer Assert Messages [Charles Ellis O'Riley Jr.]
- Charles not in attendance today; punt this to next meeting
PanicInfo::message RFC [DPC]
de-vri-esdoing some work related to this- Trying to add some kind of
AssertionInfoto aPanicInfothat the test crate can use to displays things more nicely without requiring support for colors in std
Error::type_id [unassigned]
- Should enable a way to have function specialization such that
type_idwould be specialized for every type - Priority: low
Error Handling 2021-02-01 Meeting Agenda
tags: Error Handling Minutes
Meeting Minutes
- Action items have been moved into a separate document.
- Fixing the error trait seems to have fallen off the radar, perhaps because no one is available to lead it.
- No progress on addressing the error in
rust-sv. - No follow up on blog metrics.
- Adding Backtrace to
corehad lots of discussion (i.e. suggestions on implementation approaches), though no implementation progress yet. - Discussion with the Libs team re. the
Errortrait led to a consensus that the primary role of the trait is for formatting, not downcasting; decided on a guidance for source vs. display. - Green light on changes to make error formatting more consistent.
- Adding a
panic_errorfunction similar topanic_any(though this might depend on moving theErrortrait tocore).
- Adding a
- No progress made on brainstorming topics for the
Errorbook- Setup a Doodle to figure out what time works for those who are interested in attending a brainstorming session.
- Termination trait seems to be waiting on generic member access.
- Also needs more design work re. how the final version of
Terminationshould look.
- Also needs more design work re. how the final version of
- No progress on object provider.
- No follow up on error codes
- Hold off on this until more progress has been made on the
Terminationtrait.
- Hold off on this until more progress has been made on the
- Drop the "better assert messages" issue since someone more knowledgable about it has decided to pick it up.
- Backtrace frames PR is ready to be merged.
- Progress made on the 2021 panic implementation, though we aren't explicitly tracking this issue as it's being directly implemented by Mara on the Libs team.
- Proposal for an
Issue Triagethread dedicated to sorting issues under the group's purview as soon as they're found.- Figure out how to use
@triagebotto help stay on top of issues.
- Figure out how to use