Design and implement an improved set of Error objects for arti-client
The current arti-client error types are design for implementor convenience, not user convenience: they are explicit about what kind of error they're wrapping, but not about what kind of problem they actually indicate, and what you're supposed to do about it.
We should redesign the errors exposed (directly or indirectly) by arti-client, and try to make them more generally useful. This will be an API break, so we should do this on the soon-ish side, while we're still breaking our API all the time.
We should also make sure that all of our errors are Send
and Clone
.
Edited by Nick Mathewson