4 ms·

Not having something as basic as this in the std is also a cause of painful incompatibilities and instabilities. Before anyhow became established, the ecosystem

Not having something as basic as this in the std is also a cause of painful incompatibilities and instabilities. Before anyhow became established, the ecosystem seemed to standardize on the failure crate, which was for all practical purposes basically the same thing. Making the switch wasn’t hard in my case, but also felt completely pointless.

octoberfranklin 6y ago
Is there a concise statement of the differences (aside from syntax) between failure and anyhow? Like any philosophical difference? I've been using failure and would like to know if I should switch.
- sjustinas 6y ago
  There is one in anyhow's README. https://github.com/dtolnay/anyhow#comparison-to-failure https://github.com/dtolnay/anyhow#comparison-to-failure
- JoshTriplett 6y ago
  failure prototyped changes that ultimately ended up in the standard Error trait. anyhow builds on the new standard Error trait to provide everything failure does but without the non-standard Fail type.
danieldk 6y ago
Also error-chain, which is more or less replaced by thiserror.
masklinn 6y ago
> Making the switch wasn’t hard in my case, but also felt completely pointless. I mean, failure literally says that it is experimental, that's the first thing it says. And much of its explorations were then integrated into the standard Error trait. anyhow makes it much clearer that it targets convenience for applications: it aims to be a better `Box<dyn Error>`, not to help with structured error handling but to propagate errors out of the way.
acje 6y ago
The diversity of rust through having a lot of crates delivering fairly standard functionality is a dual edged sword. It is probably good for finding optimal long term solutions, but it leads to a lot of noise. This is not a challenge limited to error handling in rust. I wish there was some process to cannibalize the most useful crates. Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? OS kernel should not panic? Service absolutely should panic and restart to maintain availability and consistency if something unexpected happens (see Erlang) and a CLI tool has a human in the loop, sometimes.
- steveklabnik 6y ago
  > I wish there was some process to cannibalize the most useful crates. There is, and this is exactly what has been happening. Early crates showed some of the weaknesses in the Error trait, and then they were addressed. Failure was created, showed more holes, and they were addressed. Now anyhow/thiserr/other stuff have happened, and their improvements may or may not make it upstream. > Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? Some of the details differ, but it feels like we're at that point to me. > OS kernel should not panic? Service absolutely should panic ... Both of these are specific implementation choices, and some people will choose different options for each of them. It just really depends. But with Result (and to some extent, the Error trait), there are means to share the bits that make sense. The core of it is broadly applicable even if some of the details change.
- dllthomas 6y ago
  > Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? I agree that "what to do about errors" differs a lot in those domains (and even more in some others, like embedded). That's not a reason not to standardize - it's something the standard needs to take into account. Ideally, if I am writing a bit of code that could be in more than one of those domains, there is something standard I can do about errors that will provide sufficient flexibility to my users that I can act appropriately to the domain I actually find myself in. Without too much complexity.

octoberfranklin 6y ago

Is there a concise statement of the differences (aside from syntax) between failure and anyhow? Like any philosophical difference? I've been using failure and would like to know if I should switch.

sjustinas 6y ago
There is one in anyhow's README. https://github.com/dtolnay/anyhow#comparison-to-failure https://github.com/dtolnay/anyhow#comparison-to-failure
JoshTriplett 6y ago
failure prototyped changes that ultimately ended up in the standard Error trait. anyhow builds on the new standard Error trait to provide everything failure does but without the non-standard Fail type.

danieldk 6y ago

Also error-chain, which is more or less replaced by thiserror.

masklinn 6y ago

> Making the switch wasn’t hard in my case, but also felt completely pointless. I mean, failure literally says that it is experimental, that's the first thing it says. And much of its explorations were then integrated into the standard Error trait. anyhow makes it much clearer that it targets convenience for applications: it aims to be a better `Box<dyn Error>`, not to help with structured error handling but to propagate errors out of the way.

acje 6y ago

The diversity of rust through having a lot of crates delivering fairly standard functionality is a dual edged sword. It is probably good for finding optimal long term solutions, but it leads to a lot of noise. This is not a challenge limited to error handling in rust. I wish there was some process to cannibalize the most useful crates. Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? OS kernel should not panic? Service absolutely should panic and restart to maintain availability and consistency if something unexpected happens (see Erlang) and a CLI tool has a human in the loop, sometimes.

steveklabnik 6y ago
> I wish there was some process to cannibalize the most useful crates. There is, and this is exactly what has been happening. Early crates showed some of the weaknesses in the Error trait, and then they were addressed. Failure was created, showed more holes, and they were addressed. Now anyhow/thiserr/other stuff have happened, and their improvements may or may not make it upstream. > Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? Some of the details differ, but it feels like we're at that point to me. > OS kernel should not panic? Service absolutely should panic ... Both of these are specific implementation choices, and some people will choose different options for each of them. It just really depends. But with Result (and to some extent, the Error trait), there are means to share the bits that make sense. The core of it is broadly applicable even if some of the details change.
dllthomas 6y ago
> Also is it even possible to standardize error handling best practices across entirely different software components like an OS kernel, a web service and a CLI tool? I agree that "what to do about errors" differs a lot in those domains (and even more in some others, like embedded). That's not a reason not to standardize - it's something the standard needs to take into account. Ideally, if I am writing a bit of code that could be in more than one of those domains, there is something standard I can do about errors that will provide sufficient flexibility to my users that I can act appropriately to the domain I actually find myself in. Without too much complexity.