Skip to content
This repository has been archived by the owner on Aug 16, 2021. It is now read-only.

error-chain deprecation #181

Open
Yamakaky opened this issue Mar 7, 2018 · 4 comments
Open

error-chain deprecation #181

Yamakaky opened this issue Mar 7, 2018 · 4 comments

Comments

@Yamakaky
Copy link

Yamakaky commented Mar 7, 2018

Hey, error-chain's maintainer here.

I have not been as active on error-chain maintenance as I should have (cf all the issues and PR). I'm also working less with Rust these times (I keep an eye on it though). Since it's not perfect anyway (rust-lang-deprecated/error-chain#190) and failure is an improvement on error-chain, I guess the best way to go would be to deprecate it and go full failure. It could be done with the 1.0 failure release.

I see a few points that should be solved before the full deprecation:

  • The doc should include a part about the transition from error-chain. I'm thinking something like "if you do this in error-chain, replace it by that in failure.
  • We need to be sure that every feature from error-chain is supported by failure.

Do you think of it?

Not sure who should be included in this discussion.

@Yamakaky Yamakaky changed the title error-chain deprecation error-chain deprecation Mar 7, 2018
@leoschwarz
Copy link

Hi. Thanks for your update.

We need to be sure that every feature from error-chain is supported by failure.

I think the biggest problem I see with this, is that the paradigms of both crates are a bit different, and in general going from error-chain to failure has involved rethinking my error handling. What's usually happened when using error-chain for me is that I end up creating ErrorKind enums with lots of variants for all possible foreign error types, so I can use try!/? everywhere, and when I port it to failure usually I only keep variants for semantic groups of errors and sometimes even box the errors. Because unlike error-chain no From conversions are implemented by failure. Instead the idea is to either map the error before trying or write your own From conversion, or if you don't care return an Error struct. (But it might be possible that I got something wrong, so please take my words with a grain of salt, I'm not involved in the development of either crate.)

My personal experience is that failure leads me to writing cleaner error handling, however I have yet to try how well it proves for debugging. Because on of the biggest selling points of error-chain for me has always been, use it everywhere (which is really easy) and you will get backtraces everywhere when you need them.

@Yamakaky
Copy link
Author

Yeah, I didn't mean a 1-1 feature mapping. I meant that the use-cases are covered.

@jonhoo
Copy link
Contributor

jonhoo commented Sep 16, 2018

Should this discussion be revisited now that the path forward for failure is a little clearer and @mitsuhiko has taken over active ownership?

@mitsuhiko
Copy link
Contributor

I feel like the issue here is now more complex as error is now being fixed in the stdlib so it's not even clear what the failure story is going to be going forward.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants