> hexyl "$(which hexyl)" --skip=-5gib
Error: Failed to jump to the desired input position. This could be
caused by a negative offset that is too large or by an input that is not
seek-able (e.g. if the input comes from a pipe).
ref: #114
This adds an error type called `ByteCountParseError` with a vanilla
`std::error::Error` implementation. The code could be significantly
compressed with a dependency like `thiserror`.
I opted to implement a separate error type for `parse_byte_count` rather
than using `anyhow`'s small ecosystem of error types there (though they
are used in `<binary>::run`) because it allows pairing diagnostic
results with tests, incl. those already written. This can be helpful in
preventing regressions in error diagnostics.
This significantly changes the structure of potential output of
top-level errors. Before, errors that have a `source` were printed on a
single line, with the `source` omitted. Now, an error with a `source`
will be printed like:
```
Error: <`Display` impl of error>
Caused by:
<`Display` impl of `source` error>
```
If there are multiple `source` errors in a chain, then it will be of the
form:
```
Error: <`Display` impl of error>
Caused by:
0: <`Display` impl of first `source` error>
1: <`Display` impl of `source` of `source` error>
# etc.
```
Now, in practice this never happened before, since the only error
type that ever could return from `<binary>::run` was `std::io::Error`,
which has no `source`. However, `source`s can start being added if, say,
future work involved using `anyhow::Context::context` or custom errors
that implement `std::Error::source` are added to the codebase. I believe
this is a good choice going forward, but I definitely want to foster
discussion and acceptance for it in the open first!
David Peter