Update for error-chain v0.12.0

[Arnavion]

trafficstars

https://github.com/rust-lang-nursery/error-chain/commit/baee12b9faa0b87e61bfd1057c0e6c1828588e7e https://github.com/rust-lang-nursery/error-chain/commit/fb9ea0e30a147e0b4d5705c8401e622ec8625b72 https://github.com/rust-lang-nursery/error-chain/commit/92a54ba9d5b7357b89e611db87819978364ad2a1 https://github.com/rust-lang-nursery/error-chain/commit/1d7157cb4808bb0ab9d87cb4b6007d8ec4f5b5d7

[reuvenpo]

I hate to be the necromancer, but... Will this ever be implemented?

[Arnavion]

Not by me.

• error-chain itself has been abandoned (again).

• Most new users don't know derive-error-chain exists, so they compare error-chain with failure and go with failure (and rightly so).

• derive-error-chain has a disadvantage with respect to needing to keep the backtrace attr in sync with error-chain's backtrace feature, which causes all sorts of problems. failure's design of requiring explicit backtraces or using Context doesn't have that problem, which is why at least one of the original users of derive-error-chain moved to it.

• Even for my own projects, I've dropped derive-error-chain for manual enums or failure.

So I don't really care to continue working on this any more. If someone makes a PR I'll be happy to merge it.

[reuvenpo]

I see. Thanks for your reply!

This will probably be off topic, but given the flux in the error-handling ecosystem right now, which crate would you recommend using, if any? I understand that failure mostly exists to experiment, and might not exist in the future too. I used to think that error-chain was the way to go, but now there isn't any one crate that looks like a clear default.

[Arnavion]

failure is fine for now.