Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collaborate on a "core::Error" crate with snafu #9

Closed
CryZe opened this issue Oct 8, 2019 · 3 comments
Closed

Collaborate on a "core::Error" crate with snafu #9

CryZe opened this issue Oct 8, 2019 · 3 comments

Comments

@CryZe
Copy link

CryZe commented Oct 8, 2019

When working on snafu's no_std compatibility, it has become clear that the situation around the lack of a core::Error or alloc::Error is really suboptimal. Introducing a whole new Error trait in snafu just for no_std seemed like it could lead to similar problems that failure had by becoming incompatible with the ecosystem. For snafu the solution is for now that it won't publicly expose an Error trait for no_std at all, but use one behind the scenes to not lose out on any of snafu's feature. This works quite well. But recently there came up the idea that maybe there could be a core-error crate, that provides an Error trait for the no_std ecosystem that could be used by snafu, anyhow, fehler and others. The crate would also have a std feature that automatically reexports the std::error::Error instead, when the feature is activated, so all the errors in your crate graph automatically get smoothly upgraded / downgraded between the different Error traits without there being any problems. And if there ever is a core::error::Error trait, it could probably backwards compatibly switch to that without having to touch either fehler, snafu or anyhow's codebase.

Considering anyhow is also planning to support no_std, this could be a good way to collaborate on an Error trait for all these crates.

@roblabla
Copy link

roblabla commented Oct 8, 2019

I started working on 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.

Work has already started in https://github.com/core-error/core-error. I'd be interested in hearing feedback on the design!

@dtolnay
Copy link
Owner

dtolnay commented Oct 8, 2019

That sounds great to me. I filed one suggestion but I am excited to see this go forward.

@dtolnay dtolnay changed the title Collaborate on a "core::Error" crate with snafu and fehler Collaborate on a "core::Error" crate with snafu Nov 28, 2019
@dtolnay
Copy link
Owner

dtolnay commented Jan 12, 2020

Closing as I don't think I need to track this here, we can follow up in issues of the core-error repo.

@dtolnay dtolnay closed this as completed Jan 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants