I haven't fully read the RFC, but wanted to drop some additional prior art. snafu::report recognizes that many errors in the ecosystem basically implement Display as write!(f, "My unique error text: {source}"), which looks terrible when trying to format a nested error as you end up with:

1: C: B: A
2: B: A
3: A

Report post-processes those error messages to remove the duplicated content, producing:

1: C
2: B
3: A

cc @yaahc, whose eyre crate has an extensive reporting mechanism.

I like the concept but I don't like much the limitation of current Display and Debug trait, you can't really do any sort of user configuration, like for example, carry information like if NO_COLOR is set in the environnement (you need to use static) thus I got no idea how we could solve this.

The fmt argument I mostly ignore all its features and just use it cause it has the write item.

I asked something very similar to tracing crate tokio-rs/tracing#2226

@shepmaster

I haven't fully read the RFC, but wanted to drop some additional prior art. snafu::report recognizes that many errors in the ecosystem basically implement Display as write!(f, "My unique error text: {source}"), which looks terrible when trying to format a nested error as you end up with:

1: C: B: A
2: B: A
3: A

The problem is that both documentations of std::error and/or std::error::Error do not mention the preferred output style for errors wrapping other errors. And it should be clarified.

I personally does not use any error reporting libraries, and use simple eprintln!("{myerror}");, which calls fmt::Display on the outmost error, resulting in unhelpful generic "failed to open file" without detail reasons. So it forces me for implements write!(f, "failed to open file: {}", self.inner) for these MyError.

In this RFC:

A new error_fmt method on std::error::Error, so that we can distinguish:

• Requests to just display an error for human consumption (Display)
• The internal implementation of printing a particular error, excluding its sources (error_fmt).

I doubt that if this can be achieved by the alternative flag {:#}. Like, print itself for {}, print the whole chain for {:#}. So that terminal users and pretty print libraries can choose their own formatting. This would be a documentation change, not a std change, and require users to follow.

Thanks to everyone for the review and comments. I've updated the RFC. Some more detailed reponses:

@shepmaster

I haven't fully read the RFC, but wanted to drop some additional prior art. snafu::report [addresses this problem]

Thanks for the reference, indeed. I wasn't aware of that. I think that this textual deduplication approach has been independently invented (at least) twice shows it's a viable strategy.

@Stargateur

I like the concept but I don't like much the limitation of current Display and Debug trait, you can't really do any sort of user configuration, like for example, carry information like if NO_COLOR is set in the environnement (you need to use static) thus I got no idea how we could solve this.

Indeed, this RFC won't eliminate the desire to do that, and it doesn't help with it very much. For example, if you want coloured error messages, you'll still need to write a reporter that prints errors in colour, and arrange to call it everywhere you print an error.

But it does make it marginally easier: at least, with this RFC, you will (eventually) be able to reliably format the individual errors without their sources being mixed in.

@oxalica

I doubt that if this can be achieved by the alternative flag {:#}

I have added a new section about this to Alternatives. As you will see from my text, I think there are serious downsides to that approach.

@joshtriplett

cc @yaahc, whose eyre crate has an extensive reporting mechanism.

Yes. One way of looking at eyre is provides errors with a better Display, by wrapping them up. I have added a reference. eyre makes printing sources depend on {} vs {:?}, so I mention that too.

GH isn't highlighting the code, could you change the fences to ```rust?

I am glad to hear of a plan to make it easy and automatic to show source chains, thus relieving the tension between showing sources in Display (DWIM for printing and logging; makes it harder for error handling code to neglect to show the sources) and not showing sources in Display (enables clean structured chain printing). I don't like the result that nearly every error will automatically have the same default Display implementation, and that that implementation will have to choose some chain formatting (the standard library mostly does not put choices of syntax into Display, except for things like integers being base 10). But, an application can always introduce its own top-level error type with choice of Display, which is already common practice with e.g. anyhow.