3 ms·
> Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I/O operations, you won't kn
by namjh 2y ago
> Consequently, this also means you cannot define two error variants from the same source type. Considering you are performing some I/O operations, you won't know whether an error is generated in the write path or the read path. This is also an important reason we don't use thiserror: the context is blurred in type.
This is true only if you add #[from] attribute to a variant. Implementing std::convert::From is completely optional. Personally I don't prefer it too as it ambiguates the context. I only use it for "trivially" wrapped errors like eyre::Report.
- skavi 2y agoYup. I absolutely would throw `#[from]` on everything when I started using thiserror, but now only do so in incredibly obvious cases like enum CarWontMove { EngineTroubles(EngineTroubles), WheelsFellOff(WheelsFellOff), } Even then, there’s often some additional context you can affix at that higher level.
- shepmaster 2y agoSNAFU follows much the same idea: we have an attribute you can add [0] when you want to allow directly implementing `From`. Like thiserror, you can also mark an error as transparent [1] when even the error existing doesn't provide useful information. [0]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#disabling-the-context-selector https://docs.rs/snafu/latest/snafu/derive.Snafu.html#disabli... [1]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#delegating-to-the-underlying-error https://docs.rs/snafu/latest/snafu/derive.Snafu.html#delegat...