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

Prevent duplicated error information in "wrapping errors" example #1375

Merged
merged 1 commit into from
Sep 28, 2020
Merged

Conversation

d-e-s-o
Copy link
Contributor

@d-e-s-o d-e-s-o commented Aug 27, 2020

The "Wrapping errors" example, which illustrates how to wrap errors, is
using the wrapped error in the text that is displayed as well as the
implementation of source(). In so doing it effectively duplicates the
error information. Such behavior does not play nice with error reporting
crates such as anyhow, eyre, and others that make use of both this data.
It is also questionable at best from a logical point of view, because,
as the name suggests, the source should be a lower level error that is
the cause of this one.
With this change we update the documentation, suggesting the usage of a
custom error string describing at a higher level what went wrong. To
keep the example simple, we did not include the actual string in the
error (a comment already suggests that this could be done), although
that probably should be done in real life to provide additional context.
An alternative approach would be to not return a source, but I figured
that it's sort of desired for the illustration of wrapping an error.

The "Wrapping errors" example, which illustrates how to wrap errors, is
using the wrapped error in the text that is displayed as well as the
implementation of source(). In so doing it effectively duplicates the
error information. Such behavior does not play nice with error reporting
crates such as anyhow, eyre, and others that make use of both this data.
It is also questionable at best from a logical point of view, because,
as the name suggests, the source should be a lower level error that is
the cause of this one.
With this change we update the documentation, suggesting the usage of a
custom error string describing at a higher level what went wrong. To
keep the example simple, we did not include the actual string in the
error (a comment already suggests that this could be done), although
that probably should be done in real life to provide additional context.
An alternative approach would be to not return a source, but I figured
that it's sort of desired for the illustration of wrapping an error.
@rust-highfive
Copy link

r? @marioidival

(rust_highfive has picked a reviewer for you, use r? to override)

@d-e-s-o
Copy link
Contributor Author

d-e-s-o commented Aug 27, 2020

See for instance this pull request that fixes exactly such a duplication of error information.

@d-e-s-o
Copy link
Contributor Author

d-e-s-o commented Aug 29, 2020

Any chance this change could get a review?

@d-e-s-o
Copy link
Contributor Author

d-e-s-o commented Aug 30, 2020

r?

@marioidival marioidival merged commit 7d3ff1c into rust-lang:master Sep 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants