Skip to content

Tracking Issue for error::Report #90172

Open
@seanchen1991

Description

@seanchen1991

Feature gate: #![feature(error_reporter)]

This is a tracking issue for a Report type that wraps an error, allowing the entire error chain to be printed in either single- or multi-line format.

Implementation PR: #91938

Public API

pub struct Report<E = Box<dyn Error>> {
    error: E,
    show_backtrace: bool,
    pretty: bool,
}

impl<E> Report<E>
where
    Report<E>: From<E>,
{
    pub fn new(error: E) -> Report<E>;
}

impl<E> Report<E> {
    pub fn pretty(mut self, pretty: bool) -> Self;
    pub fn show_backtrace(mut self, show_backtrace: bool) -> Self;
}

impl<E> From<E> for Report<E>
where
    E: Error;

impl<'a, E> From<E> for Report<Box<dyn Error + 'a>>
where
    E: Error + 'a;

impl<E> fmt::Display for Report<E>
where
    E: Error;

impl fmt::Display for Report<Box<dyn Error>>;

impl<E> fmt::Debug for Report<E>
where
    Report<E>: fmt::Display;

Unresolved Questions

  • There exists an impl<E> From<E> for Report<E> where E: Error that converts an error into a report. Is it possible to make this work for types that convert into the inner error type?

Edit(yaahc):

  • show_backtrace currently has no effect if the pretty format isn't enabled, we won't display backtraces ever in the single line format. I dislike this aspect, and am wondering if setting show_backtrace should implicitly also enable pretty, which isn't necessarily much better, but at least it's less error prone.
  • I don't like the name of pretty, in the docs we refer to it as the multi-line format, should it just be multiline?
  • I dislike how requiring the boolean for pretty/show_backtrace means you can't write something like let val = my_result.map_err(Report::new).map_err(Report::pretty).unwrap();, though I'm leaning towards this being the lesser evil compared to the issues with lifetimes and if statements on alternative builder API styles. It's not that big of a deal to introduce a closure like .map_err(|r| r.pretty(should_be_pretty))

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions