In https://github.com/signalapp/libsignal-client/pull/296#discussion_r723767841 we discussed using thiserror to remove some boilerplate in generating Error and From implementations, although we were able to use displaydoc in that PR to impl Display and decided to table the issue pending some ergonomics improvements in the upstream thiserror crate.
Solution
In https://github.com/dtolnay/thiserror/pull/155 we were able to add the necessary internal trait implementation for UnwindSafe boxed dyn Errors to enable using the declarative #[source] attribute from thiserror without needing to introduce an annoying CallbackErrorWrapper to all callsites as #296 had originally attempted. This was quickly merged and released as thiserror version 1.0.30.
Result
As in https://github.com/signalapp/libsignal-client/pull/287#discussion_r627650292 where thiserror was first proposed, there's a bit of a balancing act between pulling in an additional dependency + a potentially confusing DSL vs the ability to succinctly describe all of the ways that a variant of our crate::Error can be used at its point of definition. I think that the #[from] and #[source] attributes introduced in this PR make it easier for a client to understand the meaning of an error and also clarify more readily for future developers of this codebase how to generate a meaningful, canonical error.
Problem
In https://github.com/signalapp/libsignal-client/pull/296#discussion_r723767841 we discussed using
thiserrorto remove some boilerplate in generatingErrorandFromimplementations, although we were able to usedisplaydocin that PR to implDisplayand decided to table the issue pending some ergonomics improvements in the upstreamthiserrorcrate.Solution
In https://github.com/dtolnay/thiserror/pull/155 we were able to add the necessary internal trait implementation for
UnwindSafeboxeddyn Errors to enable using the declarative#[source]attribute fromthiserrorwithout needing to introduce an annoyingCallbackErrorWrapperto all callsites as #296 had originally attempted. This was quickly merged and released asthiserrorversion1.0.30.Result
As in https://github.com/signalapp/libsignal-client/pull/287#discussion_r627650292 where
thiserrorwas first proposed, there's a bit of a balancing act between pulling in an additional dependency + a potentially confusing DSL vs the ability to succinctly describe all of the ways that a variant of ourcrate::Errorcan be used at its point of definition. I think that the#[from]and#[source]attributes introduced in this PR make it easier for a client to understand the meaning of an error and also clarify more readily for future developers of this codebase how to generate a meaningful, canonical error.