---
# System prepended metadata

title: PEH Meeting Agenda - 2020-09-28
tags: [Minutes, Error Handling]

---

# PEH Meeting Agenda - 2020-09-28

###### tags: `Error Handling` `Minutes`

## Agenda Items

- Prototyping an implementation of `std::core::Error` and stabilizing `#[feature(backtrace)]`
- Identifying existing issues and RFCs that we should track
    - https://github.com/rust-lang/rfcs/pull/2895
- Planning for "Communicating best practices"
- "How users expect error handling to be, As in, we take a leap into the future and assume all this was implemented into the language, then how it would potentially look"
  

# Meeting Minutes

## Participants

People in attendance:
- Jane Lusby
- Sean Chen
- Ashley Mannix
- DPC
- Mukund Lakshman
- Jakub Duchniewicz
- must-compute
- Lance Zhang
- Oliver
- Charles Ellis O'Riley Jr.
- Kyle Strand
- Lokathor
- Jubilee Young

## 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](https://github.com/rust-lang/libs-team/projects/2#column-10224181)
    - [#58520 tracking issue for error source iterators](https://github.com/rust-lang/rust/issues/58520)
    - [#53487 tracking issue for RFC 2504, "fix the error trait"](https://github.com/rust-lang/rust/issues/53487)
    - [#44838 tracking issue for RFC 2011: nicer assert messages](https://github.com/rust-lang/rust/issues/44838)
    - [#2895 RFC: generic member access for dyn error trait objects](https://github.com/rust-lang/rfcs/pull/2895)
- [#66745 tracking issue for PanicInfo::message](https://github.com/rust-lang/rust/issues/66745)
- [#2945 `"C-unwind"` ABI](https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md)
- [#2820 `Box` error alias](https://github.com/rust-lang/rfcs/pull/2820)
- [#2677 RFC add the close trait](https://github.com/rust-lang/rfcs/pull/2677)
- [#2593 enum variant types](https://github.com/rust-lang/rfcs/pull/2593#issuecomment-706514374)
- [#NA must not await lint](https://github.com/rust-lang/wg-async-foundations/blob/6b423e0ca89b707534d942ac7d667a9d5f9af2f8/rfc-drafts/must_not_await_lint.md)

## 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

