error-chain
error-chain copied to clipboard
Require that errors are Send/Sync/'static.
Currently, they are not Sync because they contain a non-Sync trait object. This is a breaking change.
The decision to make errors Send but not Sync was made in #110. We believe that decision was a mistake, because it perpetuates a !Sync restriction on all users even if their errors are, in fact, Sync. Instead, users who need errors that are !Sync should use synchronization when transforming their errors into error-chain errors.
cc @aturon
I support this PR. Here are some arguments I have for supporting it.
-
io::Error
is designed to wrap other errors. This is required if anyone wants to implementRead
orWrite
and have meaningful errors.io::Error
has decided that all errors that it wraps must beSync
. This means that error-chain is fighting against the standard library. - error-chain is recursively making everyone's errors
!Sync
when they don't need to be. - If someone wants to make their errors
Sync
, but one of the causal errors is!Sync
because it uses error-chain, they can't implement thestd::error::Error
trait'scause
method. Thecause
method returns a reference, which it can't do if the causal error is behind aMutex
. - If anyone rightfully has
!Sync
data inside of their error, it would seem pretty easy to add synchronization without affecting anything else. - If this isn't fixed, I would think that any library that uses error-chain should rightfully get an issue reported that their error isn't
Sync
when it should be. I would think it would hurt adoption of error-chain in the long run.
cc @rust-lang-nursery/libs I'd like to merge this PR, any objections?
I'm in favour of this too :+1:
I have no ticky box to check off :(
Sounds great!
If everyone is in favor, can this be merged? We'll still have to get crates that use error-chain
updated to the new version, but it will definitely make interop between error-chain
and failure
crates much simpler.
@withoutboats, can you merge and publish?
Will do this week!
@withoutboats I guess you got a bit delayed? :smile:
I'd really love to see this merged.
Ooo
Ping @withoutboats :)
Did you fall into a black hole? I need this. :(
I don't believe we have the support required to add features to this library. We are currently only maintaining compatibility with rustc and not adding features.
Does that mean error-chain
is deprecated or you don't have the resources? Frankly, this change is so important to me that I'm willing to resolve merge conflict if someone is willing to review it and hit "Merge" button.
I'm most concerned with the breaking change adversely affecting users of the library. I guess I may be taking too measured an approach.
Ah, good point. Though the consensus was that this is wanted, so it may be worth it? It'd definitely need to be semver-breaking, so that people update at their own pace.
I don't think I'm alone in my assessment that error-chain
, while a useful exploration of the design space, is out of date with regards to the evolution of Rust error handling practices. If you're still actively using this crate you should consider replacing it with one of several newer crates that are actively maintained. This blog post from last year has a survey of several options, including some words on error-chain
itself.
error-chain
was a pioneer in this space, and it was the work done here that created the rust primitives (that story is probably longer, more nuanced, and only influenced by error-chain). Now, it left to show why rust needed an error-handling library. Now enums and simple macros can provide the combination of error types; a library is less important.
Right, the change would have to be breaking anyway, so might as well change the library.
Made a new pull request that adds 'Sync' via a feature toggle for backwards compatibility https://github.com/rust-lang-nursery/error-chain/pull/300