Update,
I've posted the same thing over on Reddit¹ and have gotten advice
consistent with my discussions with other people (thanks Yuya!). So
unless someone objects to any of this, I'll have a somewhat difficult
refactor ahead of my, but at least with a pretty clear plan.
Raphaël
[1]
https://old.reddit.com/r/rust/comments/wuomjt/help_needed_for_error_stratergy_inside_mercurial/
On 8/22/22 11:06, Raphaël Gomès wrote:
Hi all,
I've been having an ergonomic issue with error handling lately. Error
handling strategy used to be kind of a rough edge in Rust because of
the different constraints of both the compiler and the standard
library. Lately it seems that most projects are happy with using a mix
of `thiserror`/`anyhow`/`eyere`/`snafu`, however when investigating
using (a potential combination) of them, they don't appear to allow
for all the constraints that we have.
Rust errors in the hg codebase:
- need to be matchable at the library layers (basically that
everything inside `hg-core` exposes enums)
- need to carry enough information for end-users to make sense of the
issue and/or devs to be able to help end-users with it
- need to match the Python implementation's user-facing behavior
basically exactly (we can have some leeway for OS errors, I guess, but
the point is to leave the formatting to us and not a library)
- shouldn't do any formatting inside `hg-core`, that should be left to
consumers of `hg-core` (though having a default formatting isn't a bad
idea for debugging)
- shouldn't assume that data is somehow UTF8 (ties in to the last
point), as we have non-UTF8 data we need to format using
`format_bytes` or equivalent (no popular crate seems to care since
it's a pretty niche need)
- need to compose somehow, since not all code can be perfectly
hierarchical: the `dirstate` module needs to call functions that may
return a `RevsetError` and the `revset` module needs to call functions
that may return a `DirstateError`, creating cycles in error enums
(this is the big one for me that started this refactor and questioning).
So I'm calling to the Rust experts, or at least people that have some
experience with working in larger Rust codebases about what the
optimal strategy would be.
Thanks,
Raphaël
___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@lists.mercurial-scm.org
https://lists.mercurial-scm.org/mailman/listinfo/mercurial-devel
