4 ms·

I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just

I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just a third party crate. If the former, should I avoid learning failure patterns that are not using this crate? It sometimes feel like the language is moving too fast for me to learn it.

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.
nicoburns 8y ago
Failure is "semi-official" (It's not official, but it's created by a prominent member of the Rust community) and experimental. I believe that the general consensus is that it is to be avoided for libraries. For application development it is convenient, but not perfect and it will probably be replaced by something better at some point. > It sometimes feel like the language is moving too fast for me to learn it. It has been moving fast, but expect that to change over the next year! Most of the "Rust 2019" posts have been advocating slowing down.
babyloneleven 8y ago
The thing is that the description method in the Error trait in the stdlib is broken. I can't find the post on the internals.rust-lang.org atm, but the author of Failure has a plan for backwards compatibly fixing it and eventually moving (parts of) failure into the stdlib. The other thing about Rust error handling is the amount of boilerplate to convert between errors. Error-chain and failure are two iterations on how to deal with it. Failure seems to be the current best practices.
- dralley 8y ago
  https://github.com/rust-lang/rust/issues/53487 https://github.com/rust-lang/rust/issues/53487

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.

nicoburns 8y ago

Failure is "semi-official" (It's not official, but it's created by a prominent member of the Rust community) and experimental. I believe that the general consensus is that it is to be avoided for libraries. For application development it is convenient, but not perfect and it will probably be replaced by something better at some point. > It sometimes feel like the language is moving too fast for me to learn it. It has been moving fast, but expect that to change over the next year! Most of the "Rust 2019" posts have been advocating slowing down.

babyloneleven 8y ago

The thing is that the description method in the Error trait in the stdlib is broken. I can't find the post on the internals.rust-lang.org atm, but the author of Failure has a plan for backwards compatibly fixing it and eventually moving (parts of) failure into the stdlib. The other thing about Rust error handling is the amount of boilerplate to convert between errors. Error-chain and failure are two iterations on how to deal with it. Failure seems to be the current best practices.

dralley 8y ago
https://github.com/rust-lang/rust/issues/53487 https://github.com/rust-lang/rust/issues/53487