Error Handling Project Group

[KodrAus]

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).

[KodrAus]

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 Backtrace in core.
• Going with the trait-based impl for Backtrace in 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 Error to core
• should we do a trait object based solution internally with an unstable Backtrace
  trait in core and a stable Backtrace type in core or should it use global hooks
  like panic_impl
• need a prototype solution for exposing Backtrace as a type in core with the interface it currently provides in std

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
  • #53487 tracking issue for RFC 2504, "fix the error trait"
  • #44838 tracking issue for RFC 2011: nicer assert messages
  • #2895 RFC: generic member access for dyn error trait objects
• #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?

• Error in core.
• Stabilization of unstable Error interfaces.
• 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

[KodrAus]

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_std so 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 backtrace anymore

The Rust Error Book

• We now have a folder in the project-error-handling repository 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-provider that the RFC would like to use
• Once the content is updated it needs some Libs input
• There could be some tie in with tide's Response type?

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: Tracking issue for allowing overlapping implementations for marker trait rust#29864
  • negative trait impls
  • dynamic vtable type_id (like C++ typeid keyword) RFC: Pointer metadata & VTable rfcs#2580
  • final keyword -> no overriding of trait any more
  • new trait TypeInfo RFC: TypeInfo rfcs#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-macros and syn?
  • Need external thoughts/mentorship on this question

Iterating over Backtrace frames

• Just starting out, so there hasn't been much discussion yet
• The backtrace crate has a frames() fn that already exposes its individual frames
• We could propose basically the same thing for std's Backtrace type

[KodrAus]

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: Implement Error for &(impl Error) rust#75180

dyn Error or impl Error?

• We think the recommendation of &(dyn Error + 'static) for borrowed abstract errors and impl Error + Send + Sync + 'static for 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 Backtrace doesn'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::backtrace and backtrace.

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::frames should 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!

[KodrAus]

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: Error objects and additionally captures context relevant to those errors.
• Maybe extend this type to also handle PanicInfo objects
  - Should naturally fit the design of the Error trait
  - PanicInfo already has this handled by the hook from set_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 Vec behind a wrapper
  • additional suggestions forthcoming

Nicer Assert Messages [Charles Ellis O'Riley Jr.]

• Charles not in attendance today; punt this to next meeting

PanicInfo::message RFC [DPC]

• de-vri-es doing some work related to this
• Trying to add some kind of AssertionInfo to a PanicInfo that 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_id would be specialized for every type
• Priority: low

[KodrAus]

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 core had lots of discussion (i.e. suggestions on implementation approaches), though no implementation progress yet.
• Discussion with the Libs team re. the Error trait 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_error function similar to panic_any (though this might depend on moving the Error trait to core).
• No progress made on brainstorming topics for the Error book
  • 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 Termination should look.
• No progress on object provider.
• No follow up on error codes
  • Hold off on this until more progress has been made on the Termination trait.
• 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 Triage thread dedicated to sorting issues under the group's purview as soon as they're found.
  • Figure out how to use @triagebot to help stay on top of issues.