[namjh]

> 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]

Yup. 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]

SNAFU 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#disabli...

[1]: https://docs.rs/snafu/latest/snafu/derive.Snafu.html#delegat...