Should failure be split into separate crates?

[epage]

I used failure when prototyping 3 crates and recently had to rip it out on the path to 1.0. I suspect splitting failure up will help aid in the path to a stable Fail trait that doesn't need to be ripped out.

failure today provides a ecosystem wide vocabulary term (Fail), implementation helpers (failure-derive, bail, etc), and a catch-all Fail implementation (Error) that imo atm is best suited for bins and prototyping. The compatibility guarantees for each of these set of tools is different. In addition, I feel that a simplified version of Fail` would not be contentious on its own and could be stablized quickly. These combined provide a path to stablization.

RE Fail

When I evaluated Fail, I found most of my concerns to be with Context and Error. Context doesn't feel essential to the trait (could be an extension trait) and feels tied to Error (creates complex types that people will probably not return but instead return erased versions).

RE Ripping failure out

I used failure when prototyping 3 crates and recently had to rip it out on the path to 1.0.

Only 2 of the crates are moving to 1.0 but I had to at least remove failure::Error from the third because Error doesn't play nice with being a cause.

My proposal

Split the crate into:

• failure-fail:
  • Fail trait without Context support
  • Possibly include Compat and/or SyncFailure
• failure-derive
• failure-error
  • Helper macros
  • Error
  • Context
• failure as a facade that integrates the pieces together?

Potential areas to still resolve in Fail

• causes including the current error or not (name implies it doesn't, implementation does)
• root_cause could be the current error
• What, if any, integration should be done with the Termination trait
• Duplicate implementations with same name #211 fns duplicated between trait and impl
• About the Sync requirement #201 Sync requirement

[BurntSushi]

See also #209 where there is some discussion about potentially moving the Fail trait to std. A separate crate could be a decent middle (or migratory) ground. A key thing we want to minimize is breaking the ecosystem that has begun using failure in their public APIs.

[epage]

A key thing we want to minimize is breaking the ecosystem that has begun using failure in their public APIs.

I'm glad you at least said "minimize".

Personally, I have found the stability concerns during failures development very off putting especially for something so fundamental and on the path to std. It feels coercive in pushing a specific design rather than us being able to consider what the design should be. It feels like a flag that gets raised to shutdown the conversation. failure is 0.1 and people were warned that things might break and to limit usage to where you can absorb that. We should be willing to break compatibility at this stage.

[BurntSushi]

@epage I don't necessarily disagree. I'd appreciate if we all assumed good faith though, and not insinuate that anyone is trying to "shutdown the conversation." It's one thing to warn people that failure is experimental, and another to put that policy into practice. e.g., crates.io reports that failure already has over 500 dependent crates. That's a whole lot of breakage! And when we do break it, people are going to (rightfully) get upset.

But yes, this is why I said "minimize." I do think it needs to be a strong consideration in whatever action we take. People have limited patience to deal with this sort of thing; we should respect that.

[epage]

I don't necessarily disagree. I'd appreciate if we all assumed good faith though, and not insinuate that anyone is trying to "shutdown the conversation."

I'm sorry; it was not my intention to prescribe motivation. My intention was more so to describe how it comes across and impacts people's perception, their trust of the process, and their willingness to give feedback. Honestly, it is one of the reasons I've generally steered clear of the conversations here even though I think the goals are admirable and want to see those goals achieved.

[dekellum]

2¢: The project going dormant for ~6 months has lowered my expectations, such that I'd view breaking changes actually merged to master, for sound reasons, as progress here! Just respect semvar (0.2 is sufficient) when breaking it, and be open to possibility of back-porting some non-breaking fixes or transitional aids to 0.1.x as well.

[njaremko]

@mitsuhiko Has taken ownership of the project as of a few days ago. So development has resumed.
Also, @withoutboats has published an RFC proposing improvements to the std Error type: https://github.com/rust-lang/rfcs/blob/fix-error/text/0000-fix-error.md

[mitsuhiko]

I'm going to close this now. Failure right now will continue to be what it is until it's clear what happens with the new error trait in std.

The conversation about this can be found here: rust-lang/rfcs#2504