5 ms·

With the anyhow crate and ? syntax I find current rust error handling a pleasure to work with. Of course there are a few rough edges, but nothing major. I also

With the anyhow crate and ? syntax I find current rust error handling a pleasure to work with. Of course there are a few rough edges, but nothing major. I also don't mind having to wrap the successful result of a fn in Ok(...). I hope "do a few minor things, add better documentation, but leave the language itself as it is" is also one of the possible outcomes...

tadzik_ 6y ago
Indeed. Perhaps standarizing something along the lines of anyhow/thiserror and documenting it as an upgrade path for those who want it is all they need to do. Or maybe there's some cool ideas yet undiscovered. Great to see that it's being acknowledged as a problem (or at least a documentation problem) – there's a lot of people who've never heard of anyhow and their stance is just "ugh, error handling is a PITA".
- codeflo 6y ago
  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.
captainmuon 6y ago
I haven't done much in Rust yet, but it seems you can either use `Result` to handle errors (and force the caller to deal with it) or crash with `panic`. I wonder, is there any way to specify "Crash, unless someone up the call stack deals with this?". What I usually do in other languages is use exceptions as assertions, when it is just a simple one-off app, but then go back and catch the exceptions when possible to make it more user friendly and robust. It seems that exceptions have been omitted on purpose, but is there another way to express this idiom in Rust?
- masklinn 6y ago
  > I haven't done much in Rust yet, but it seems you can either use `Result` to handle errors (and force the caller to deal with it) or crash with `panic`. I wonder, is there any way to specify "Crash, unless someone up the call stack deals with this?" It's possible to catch panics during unwinding[0], but that will not work in every case: `panic='abort'` is a completely valid configuration for a Rust compilation. > What I usually do in other languages is use exceptions as assertions Rust assertion macros will panic. `unwrap` methods are also, functionally, assertions. And they panic. > when it is just a simple one-off app, but then go back and catch the exceptions when possible to make it more user friendly and robust. It seems that exceptions have been omitted on purpose, but is there another way to express this idiom in Rust? That is very much not idiomatic rust[1] and I would recommend against it, but it is possible for applications as you'd hopefully be controlling the compilation configuration. For libraries however it's a good way to shoot everyone in the foot: you simply can not assume that users of your library will `panic='unwind'`, so it is a very dangerous thing to do. [0] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [1] https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...
- imron 6y ago
  > but is there another way to express this idiom in Rust? If you don’t want to handle Results, just ? all the way up and out of main. Then come back and deal with them as necessary when you’re ready. It’s far nicer than dealing with exceptions.
Qwuke 6y ago
I think there are good improvements to be had in the async side of the ecosystem, but I do agree that Rust error handling is the most delightful of any language I've regularly used.
mjw1007 6y ago
This is a project group under the "libs" team (ie, the team responsible for the standard library). So I don't think language changes are going to come out of it.

tadzik_ 6y ago

Indeed. Perhaps standarizing something along the lines of anyhow/thiserror and documenting it as an upgrade path for those who want it is all they need to do. Or maybe there's some cool ideas yet undiscovered. Great to see that it's being acknowledged as a problem (or at least a documentation problem) – there's a lot of people who've never heard of anyhow and their stance is just "ugh, error handling is a PITA".

codeflo 6y ago
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.

captainmuon 6y ago

I haven't done much in Rust yet, but it seems you can either use `Result` to handle errors (and force the caller to deal with it) or crash with `panic`. I wonder, is there any way to specify "Crash, unless someone up the call stack deals with this?". What I usually do in other languages is use exceptions as assertions, when it is just a simple one-off app, but then go back and catch the exceptions when possible to make it more user friendly and robust. It seems that exceptions have been omitted on purpose, but is there another way to express this idiom in Rust?

masklinn 6y ago
> I haven't done much in Rust yet, but it seems you can either use `Result` to handle errors (and force the caller to deal with it) or crash with `panic`. I wonder, is there any way to specify "Crash, unless someone up the call stack deals with this?" It's possible to catch panics during unwinding[0], but that will not work in every case: `panic='abort'` is a completely valid configuration for a Rust compilation. > What I usually do in other languages is use exceptions as assertions Rust assertion macros will panic. `unwrap` methods are also, functionally, assertions. And they panic. > when it is just a simple one-off app, but then go back and catch the exceptions when possible to make it more user friendly and robust. It seems that exceptions have been omitted on purpose, but is there another way to express this idiom in Rust? That is very much not idiomatic rust[1] and I would recommend against it, but it is possible for applications as you'd hopefully be controlling the compilation configuration. For libraries however it's a good way to shoot everyone in the foot: you simply can not assume that users of your library will `panic='unwind'`, so it is a very dangerous thing to do. [0] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html [1] https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...
imron 6y ago
> but is there another way to express this idiom in Rust? If you don’t want to handle Results, just ? all the way up and out of main. Then come back and deal with them as necessary when you’re ready. It’s far nicer than dealing with exceptions.

Qwuke 6y ago

I think there are good improvements to be had in the async side of the ecosystem, but I do agree that Rust error handling is the most delightful of any language I've regularly used.

mjw1007 6y ago

This is a project group under the "libs" team (ie, the team responsible for the standard library). So I don't think language changes are going to come out of it.