anyhow::Error does not implement std::error::Error

[L-as]

Is this an oversight or is there some inherent limitation that causes this?

Thanks

[dtolnay]

This is intentional. That impl would be incoherent with the existing pair of impls impl From<T> for T (libcore) and impl<E> From<E> for anyhow::Error where E: std::error::Error + Send + Sync + 'static (? support).

error[E0119]: conflicting implementations of trait `std::convert::From<anyhow::Error>` for type `anyhow::Error`:
   --> src/error.rs:313:1
    |
313 | / impl<E> From<E> for Error
314 | | where
315 | |     E: std::error::Error + Send + Sync + 'static,
316 | | {
...   |
320 | |     }
321 | | }
    | |_^
    |
    = note: conflicting implementation in crate `core`:
            - impl<T> std::convert::From<T> for T;

[L-as]

Thanks for the explanation! I haven't given this much thought, but couldn't you have some function of the type `anyhow::Error -> impl std::error::Error`, which is consistent with the current Deref implementation? 火, 1月 12, 2021 at 19:53, David Tolnay <notifications@github.com> が送信：

…

This is intentional. That impl would be incoherent with the existing pair of impls impl From<T> for T (libcore) and impl<E> From<E> for anyhow::Error where E: std::error::Error + Send + Sync + 'static (? support). error[E0119]: conflicting implementations of trait `std::convert::From<anyhow::Error>` for type `anyhow::Error`: --> src/error.rs:313:1 | 313 | / impl<E> From<E> for Error 314 | | where 315 | | E: std::error::Error + Send + Sync + 'static, 316 | | { ... | 320 | | } 321 | | } | |_^ | = note: conflicting implementation in crate `core`: - impl<T> std::convert::From<T> for T; — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#136 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFINPUHSXCTTKTIX6QLZW73SZSSFLANCNFSM4V7WXUZA).

[dtolnay]

You can generate such a function using thiserror:

use thiserror::Error;

#[derive(Error, Debug)]
#[error(transparent)]
struct Error(anyhow::Error);

Now Error(...) is a function with the signature anyhow::Error -> impl std::error::Error where the resulting error impl has a source/display/backtrace consistent with the argument.

[L-as]

Thanks! 火, 1月 12, 2021 at 20:55, David Tolnay <notifications@github.com> が送信：

…

You can generate such a function using [thiserror](https://github.com/dtolnay/thiserror): use thiserror :: Error; #[derive(Error, Debug)] #[error(transparent)] struct Error (anyhow :: Error); Now Error(...) is a function with the signature anyhow::Error -> impl std::error::Error where the resulting error impl has a source/display/backtrace consistent with the argument. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#136 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFINPUCGMBCOKQGFRJ7DMRTSZSZNFANCNFSM4V7WXUZA).

[cipriancraciun]

Why I understand the technical reason why the Rust compiler wouldn't allow anyhow::Error to also implement std::error::Error, I wouldn't just blame the compiler, but I would instead take a second look at the impl From<E> for anyhow::Error where E : std::error::Error ....

At the moment the anyhow library makes it trivial to just convert from any std::error::Error into an anyhow::Error without any other additional trait import (because it relies on From<E>), which is great for the library developer using anyhow! All errors, no mater of the type, are quickly gobbled into a generic anyhow::Error.

However, downstream, when another developer needs to use a library that relies on anyhow::Error, and if he chooses some other "great error library" he just hits a wall and has to treat anyhow special...

So, any error is easily gobbled up into an anyhow::Error, however once there you can't rely anymore on traits working. Thus anyhow doesn't play nice with other error libraries out there.

---

Thus, could we find a compromise where anyhow::Error does actually implement std::error::Error like any good behaved error? :)

(Or at least a workaround for other "great error library" implementers out there?)