3 ms·
> Another problem is you can't both implement the `Error` trait and support `From` from anything that implements the `Error` trait because it will conflict with
by couchand 7y ago
> Another problem is you can't both implement the `Error` trait and support `From` from anything that implements the `Error` trait because it will conflict with Rust's blanket implementation of `From` converting yourself into yourself.
I believe this issue would only come up if you're trying:
impl<T: std::error::Error> From<T> for MyError
which seems like a really clumsy way to handle it. In most real cases, wouldn't you write the From impls for the specific types of errors you're expecting?
- epage 7y ago> which seems like a really clumsy way to handle it. In most real cases, wouldn't you write the From impls for the specific types of errors you're expecting? In an application, yes. The problem is in libraries because the `From`s` are public so you have put the error type for your dependency in your public API and if you change dependencies or upgrade past a major, you've broken your API. Granted, it is unlikely someone is going to use it ... but I wouldn't put it past people to take shortcuts like that.
- shepmaster 7y agoA benefit of SNAFU is that the `From` trait is implemented against the internal-by-default context selectors. Since enum variants are public if the enum is, SNAFU also offers a way to wrap an opaque newtype around the internal error, allowing the implementor to choose exactly what public API their error exposes.