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
