Improve Interoperability with Error Reporting Tools #355
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduction
I recently opened an issue (#354) thinking that there was a bug in this crate, but the problem that I was having tourned out to be caused by a bug from
serde
. While I was going through the source code of this crate I noticed a minor thing that could, at least according to my personal opinion, be improved. Given the great value that I was able to get from this library, I thought I could attempt to give a small contribution torust-csv
and implemented this PR.Before describing my proposal, I'd just like to clarify that although I opened a PR, I don't think that the code I'm presenting is necessarily ready to be merged yet. I've submitted it just so that we discuss the changes while looking at something concrete. The code compiles and passes all the tests.
Problem Description
The issue I'm having is with the way in which errors from this crate are formatted in their
Display
trait. In particular, if anycsv::Error
has a source error, it will be formatted as"<error description>: <source description>"
. The resulting string is hard to read, especially when the error chain is long.Chaining errors descriptions by placing them in the same string and separating them with a colon is a simple, common practice. I was doing the same until a few months ago, when I've come across
anyhow
andeyre
. Now I use them to format my errors and the legibility of my logs has greatly improven as a consequence.Unfortunately,
csv::Error
currently doesn't play nicely with these tools. The first reason is, of course, that it manually handles the formatting of its source. The second is that it doesn't implementstd::error::Error::source
, so thateyre
isn't able to follow the error trace and print it.Proposed Solution
This PR would fix both of the issues I've just described.
First of all, it adds an implementation for
std::error::Error::source
, which would improve the interoperability with error reporting tools I've just described. It would also allow any client code to usestd::error::Error::source
and would better model the semantics of the errors thatrust-csv
produces.Secondly, it changes the implementation of
Display
forcsv::Error
so that the resulting string doesn't include the source error anymore, leaving this task toeyre
and similar libraries.I've also updated the tutorial so that now most of the example report their errors with
eyre
. I've done it in order to be proactive, but it's the change I'm less confident about: on one hand readers might not want to bothereyre
, but on the other if they were to run the examples without it they wouldn't be getting a complete description of the error, which might be confusing. Moreover, one of the tests associated with the tutorial relies on the description of a nested error being present, so it would break ifeyre
were not used.Finally, I've not added
eyre
to the cookbook, because it didn't seem worth it, but I can fix this if you prefer.