5 ms·

`failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`. There is an RFC for

by epage 8y ago

`failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`. There is an RFC for pulling some of the trait improvements into the language. After that, I believe they plan to continue to iterate on the design of the failure crate. The general recommendation I make and see from others is that `failure` is far from stable. Feel free to use it in applications but avoid it for libraries.

the_duke 8y ago
That RFC was accepted and merged quite a while ago! https://github.com/rust-lang/rfcs/pull/2504 https://github.com/rust-lang/rfcs/pull/2504
zanny 8y ago
Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines of error handling. It still does all the exact same stuff, and if you use its generic Error impl it behaves the exact same way as the std trait. If Failure stops getting updated.. fine? It doesn't need changing if it works right now, on the 0.1.3 release, for you. If Rust's error trait changes it breaks all libraries anyway and would only happen in the next edition. Thats probably three years out!
- epage 8y ago
  > Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. If you expose failure in your public API and failure makes a breaking change, it is a breaking change for your API because your clients need to be on a compatible version of failure.
  - zanny 8y ago
    Your clients don't though, you can have multiple versions of a crate in your build tree. Your failures aren't then compositable with newer failures as failures but they do impl Error and can be used as standard errors. The alternative is to just use... standard errors anyway? With the aforementioned sizable boilerplate? There's no downside to failure unless there's a less volatile error replacement you'd use instead.
    - burntsushi 8y ago
      That you can have multiple versions of your crate is exactly what enables the issues caused by public dependencies. It's not about multiple versions of your crate, but rather, multiple versions of the failure crate. If failure 0.2 is released (and doesn't use the semver trick), then you'll have two versions of the Fail trait, and thus, two versions of the failure::Error trait object. Madness then ensues for anyone using failure::Error (or dyn Fail in general). failure is a victim of its own success. I think most everyone believes it's pretty close to what we want Rust's error handling story to look like. But it's a public dependdncy and everyone started using it. Now it's more difficult to evolve.
    - epage 8y ago
      > Your clients don't though, you can have multiple versions of a crate in your build tree Yes, but you can only directly depend on one version of failure. What happens if you directly depend on two libraries with different versions of failure? How do you interop with them? In a lot of cases, you'll be lucky and not need to reference the types in any way and it will "just work". This breaks down if you do need to reference the types.

by epage 8y ago

the_duke 8y ago

That RFC was accepted and merged quite a while ago! https://github.com/rust-lang/rfcs/pull/2504 https://github.com/rust-lang/rfcs/pull/2504

zanny 8y ago

Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. Coinciding with the 2018 edition release I ported one of my libraries to it that was using vanilla std::Error impls for two years and dropped about ~400 LOCs out of 600 lines of error handling. It still does all the exact same stuff, and if you use its generic Error impl it behaves the exact same way as the std trait. If Failure stops getting updated.. fine? It doesn't need changing if it works right now, on the 0.1.3 release, for you. If Rust's error trait changes it breaks all libraries anyway and would only happen in the next edition. Thats probably three years out!

epage 8y ago
> Anything that would break failure in libraries written now would break all libraries because it would mean the fundamental Error trait has changed. Since failure is Error compatible you don't lose anything using it. Its only ~2500 lines of Rust. If you expose failure in your public API and failure makes a breaking change, it is a breaking change for your API because your clients need to be on a compatible version of failure.
- zanny 8y ago
  Your clients don't though, you can have multiple versions of a crate in your build tree. Your failures aren't then compositable with newer failures as failures but they do impl Error and can be used as standard errors. The alternative is to just use... standard errors anyway? With the aforementioned sizable boilerplate? There's no downside to failure unless there's a less volatile error replacement you'd use instead.
  - burntsushi 8y ago
    That you can have multiple versions of your crate is exactly what enables the issues caused by public dependencies. It's not about multiple versions of your crate, but rather, multiple versions of the failure crate. If failure 0.2 is released (and doesn't use the semver trick), then you'll have two versions of the Fail trait, and thus, two versions of the failure::Error trait object. Madness then ensues for anyone using failure::Error (or dyn Fail in general). failure is a victim of its own success. I think most everyone believes it's pretty close to what we want Rust's error handling story to look like. But it's a public dependdncy and everyone started using it. Now it's more difficult to evolve.
  - epage 8y ago
    > Your clients don't though, you can have multiple versions of a crate in your build tree Yes, but you can only directly depend on one version of failure. What happens if you directly depend on two libraries with different versions of failure? How do you interop with them? In a lot of cases, you'll be lucky and not need to reference the types in any way and it will "just work". This breaks down if you do need to reference the types.