You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 16, 2021. It is now read-only.
With the recent proliferation of error-handling crates, it has become clear that the situation around the lack of a core::error::Error is really suboptimal. In snafu, no_std support is being introduced through a whole new Error trait just for no_std - which could lead to similar problems that failure had by becoming incompatible with the ecosystem.
Ideally, the Error trait would show up in core, but due to coherence concerns and std-dependent features being added to std::error::Error, a resolution is unlikely to happen soon. As such, I propose making a new crate, core-error - exposing our own version of the Error trait. The goal of this crate is twofolds:
Provide a common trait for various error handling crates (Failure, Snafu, Fehler, Anyhow, error_chain, and any other)
Allow no_std libraries that don't want to depend on a specific error handling crate to still expose errors that can interoperate with those libraries.
Such a crate would work like this:
With the std feature, it just re-export std::error::*
With no-default-features, it exposes an Error trait similar to the one in std but without backtraces, and without the std/alloc-only impls.
Rustc version auto-detection is used to figure which errors to implement the trait on.
The alloc feature enables downcasting, in addition to supporting alloc errors
The crate would compile on all versions from 1.0.0 to the latest stable version.
The trait will be compatible with std's Error trait, and if libcore gains an Error trait in the future, it should be compatible with it too.
Once the crate reaches 1.0.0, I'll consider it ready for integration in the various error crates and will follow the same stability guarantee Rust does: No breaking changes ever.
I'm onboard with a core-error, but I don't really have the bandwidth to provide feedback at the moment. Once it reaches 1.0—personally speaking—I think it ought be integrated with Failure!
With the recent proliferation of error-handling crates, it has become clear that the situation around the lack of a
core::error::Error
is really suboptimal. Insnafu
,no_std
support is being introduced through a whole new Error trait just forno_std
- which could lead to similar problems thatfailure
had by becoming incompatible with the ecosystem.Ideally, the
Error
trait would show up in core, but due to coherence concerns and std-dependent features being added tostd::error::Error
, a resolution is unlikely to happen soon. As such, I propose making a new crate,core-error
- exposing our own version of theError
trait. The goal of this crate is twofolds:Such a crate would work like this:
std::error::*
no-default-features
, it exposes anError
trait similar to the one instd
but without backtraces, and without the std/alloc-only impls.The trait will be compatible with std's Error trait, and if libcore gains an Error trait in the future, it should be compatible with it too.
Once the crate reaches 1.0.0, I'll consider it ready for integration in the various error crates and will follow the same stability guarantee Rust does: No breaking changes ever.
Work has already started in https://github.com/core-error/core-error. I'd be interested in hearing feedback on the design.
The text was updated successfully, but these errors were encountered: