-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Open
Labels
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: 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.Relevant to the library API team, which will review and decide on the PR/issue.
Description
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 thepretty
format isn't enabled, we won't display backtraces ever in the single line format. I dislike this aspect, and am wondering if settingshow_backtrace
should implicitly also enablepretty
, 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 bemultiline
? - I dislike how requiring the boolean for
pretty
/show_backtrace
means you can't write something likelet 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))
saona-raimundo, brooksprumo, loqusion, brookelew, rkeulemans and 1 more
Metadata
Metadata
Assignees
Labels
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: 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.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
yaahc commentedon 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 formain
.[-]Tracking Issue for error::Reporter[/-][+]Tracking Issue for `error::Report`[/+]yaahc commentedon 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 instd
at some point for storing errors which are only meant to be reported, similar toanyhow::Error
oreyre::Report
. If we do introduce such a type in the future it might make more sense for that type to be the one namedReport
, 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 commentedon 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 thatReport<E>
can be used with the?
operator if I had to change error types when creating a report from an error?HTGAzureX1212 commentedon Sep 4, 2022
After some brief investigation, such an implementation would not work due to a conflicting blanket implementation in core.
HTGAzureX1212 commentedon Sep 4, 2022
A little bit more context for the rationale, I encountered this error when trying to convert a
Reoprt<F>
to aReport<E>
givenE: From<F>
:map_report
is a trait extension function I added toResult<T, E>
that does this: