Skip to content
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

Tracking Issue for error::Report #90172

Open
seanchen1991 opened this issue Oct 22, 2021 · 5 comments
Open

Tracking Issue for error::Report #90172

seanchen1991 opened this issue Oct 22, 2021 · 5 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@seanchen1991
Copy link
Member

seanchen1991 commented Oct 22, 2021

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))
@seanchen1991 seanchen1991 added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 22, 2021
@yaahc
Copy link
Member

yaahc commented Jan 7, 2022

Regarding the first unresolved issue about making it convert the inner type, I don't think its possible to do it generally, but I was able to add a special case for Box<dyn Error> https://github.com/rust-lang/rust/pull/91938/files#diff-6605ea65189fd18a801464d4718ad307bb93be455d1592603ebf9382063902b2R1388 so that it boxes and wraps the error at the same time, which should make it work nicely as the return type for main.

@yaahc yaahc changed the title Tracking Issue for error::Reporter Tracking Issue for error::Report Jan 10, 2022
@yaahc
Copy link
Member

yaahc commented Mar 28, 2022

I want to raise a concern on this related to naming. I think it's not unlikely that we may want to have a Box<dyn Error> equivalent type in std at some point for storing errors which are only meant to be reported, similar to anyhow::Error or eyre::Report. If we do introduce such a type in the future it might make more sense for that type to be the one named Report, or something else that clearly communicates that it semantically represents an error which is no longer expected to be handled anymore other than via reporting.

It might make more sense to call this std::error::Reporter or something along those lines. For now though I think it's fine to leave it as is. I'm in no rush to stabilize this interface.

@HTGAzureX1212
Copy link
Contributor

HTGAzureX1212 commented Sep 3, 2022

Not sure whether it would be in scope of this issue, but would it be possible for a impl<E, F> From<Report<F>> for Report<E> where E: Error + From<F>, F: Error be added such that Report<E> can be used with the ? operator if I had to change error types when creating a report from an error?

@HTGAzureX1212
Copy link
Contributor

After some brief investigation, such an implementation would not work due to a conflicting blanket implementation in core.

@HTGAzureX1212
Copy link
Contributor

A little bit more context for the rationale, I encountered this error when trying to convert a Reoprt<F> to a Report<E> given E: From<F>:

error[E0277]: `?` couldn't convert the error to `Report<GatewayError>`
  --> hartex-gateway\src\main.rs:36:34
   |
36 |     dotenv::dotenv().map_report()?;
   |                                  ^ the trait `From<Report<hartex_core::dotenv::Error>>` is not implemented for `Report<GatewayError>`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following other types implement trait `From<T>`:
             Report<Box<(dyn std::error::Error + 'a)>>
             Report<E>
   = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, Report<hartex_core::dotenv::Error>>>` for `Result<(), Report<GatewayError>>`

map_report is a trait extension function I added to Result<T, E> that does this:

self
    .map_err(E::from)
    .map_err(Report::new)
    .map_err(|report| report.pretty(true).show_backtrace(true))
            ```

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants