Hacker News Reader

Comment by rklaehn | Hacker News Reader

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...

View on HN

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".

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.

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.

There is one in anyhow's README.

https://github.com/dtolnay/anyhow#comparison-to-failure

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.

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

> 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.

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.

> 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.

> 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.

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?

> 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

[1] https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-pa...

> 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.

Also `anyhow` exists specifically to support that use-case: you're developing an application and you largely just want to bubble up errors and show them to the user, with the odd spot of internal handling.

but it seems you can either use `Result` to handle errors (and force the caller to deal with it) or crash with `panic`

To me, there is a large difference between them.

Result is for computations that can fail, such as opening a file or reading from a socket. Computations that fail should be handled by the caller (e.g. report a nice error which file could not be opened or attempting to open a new socket and retry the communication).

panic, in particular through assertions, are for catching programming errors, such as violation of invariants. These are cases where the program should just crash and burn, because it would be in an invalid state otherwise. E.g. splitting a Vec at an invalid index is a programming error. If a program attempts such a split, it is already in an invalid state, so it should crash and the bug should be fixed.

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.

The Rust equivalent is letting Result::Err bubble up the call chain and have a

  fn main() -> Result<(), Error>

or even nicer:

  fn main() -> anyhow::Result<()>

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.

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.

Reply on news.ycombinator.com