7 ms·

Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is

Rust error handling is great for reliable systems. But it used to be really annoying when just doing exploratory coding. With the anyhow crate, this problem is solved as well. Just use anyhow if you just want to try something out quickly without being slowed down by error type mismatches, and then later refine it to a handcrafted error type. I prefer rust error handling over all other languages I worked with (scala, java, C++, C, javascript, typescript, ...).

egnehots 6y ago
for exploratory coding you can also just unwrap, assert, panic.. It's useful to remember that error handling is optional in those cases :)
- unrealhoang 6y ago
  anyhow with ? is even shorter than unwrap. If it’s likely to have error at some point, I’d throw in a .context, it is so convenient. Edit: typo.
  - edflsafoiewq 6y ago
    ? requires the return type be annotated with an error type and the success case be annotated with Ok, for all functions up the stack, between the current function and where handling occurs. unwrap is purely local.
    - rklaehn 6y ago
      I somehow still prefer ?, even in places where unwrap would be perfectly fine, like tests. unwrap is somehow unpleasant to look at. E.g. you can have tests that return an anyhow::Result<()>, and use ? anywhere in the test. The test will fail if the result is not Ok(()). Sure, you have the additional boilerplate of the return type annotation and the final Ok(()), but the test logic itself reads nicer, I think.
simias 6y ago
Completely agree. I used to create my own error type(s) manually and implement the various conversions for 3rd party crates and it was quite a lot of boilerplate but with anyhow (for applications where you don't really care about strict error types) and thiserror (when you need to be a little more thorough). Actually that's effectively TFA's solution, if they had used thiserror/anyhow from the start there might not have been an issue to begin with. Admittedly it took me a while to find these crates since they're not part of std. Maybe the community should come together to create a curated list of third party crates that should probably be known by all Rust devs? Crates like thiserror, anyhow, rand, serde, clap and other "de-facto standard" crates?
- wronghorse 6y ago
  This is really interesting because I recently found the anyhow crate and I was wondering why it's not mentioned anywhere else. Definitely feels like useful information that a newly minted Rust dev could make use of.
  - simias 6y ago
    Indeed. I wish I learned about it earlier myself, it would've saved me some boilerplate in the past.
nwellnhof 6y ago
> Rust error handling is great for reliable systems. Last time I checked, Rust couldn't even catch malloc failures.
- wizzwizz4 6y ago
  To be fair, these days malloc doesn't fail; your program crashes when it tries to use the memory, and there's nothing you can do about it. (But I agree that this is a problem with Rust's alloc system.)
  - folmar 6y ago
    It can, it just doesn't when the 0physical memory is exhausted, but there are other conditions $ ulimit -v 10240 < printf("%p\n", malloc(1024*1024*128)); > nil

egnehots 6y ago

for exploratory coding you can also just unwrap, assert, panic.. It's useful to remember that error handling is optional in those cases :)

unrealhoang 6y ago
anyhow with ? is even shorter than unwrap. If it’s likely to have error at some point, I’d throw in a .context, it is so convenient. Edit: typo.
- edflsafoiewq 6y ago
  ? requires the return type be annotated with an error type and the success case be annotated with Ok, for all functions up the stack, between the current function and where handling occurs. unwrap is purely local.
  - rklaehn 6y ago
    I somehow still prefer ?, even in places where unwrap would be perfectly fine, like tests. unwrap is somehow unpleasant to look at. E.g. you can have tests that return an anyhow::Result<()>, and use ? anywhere in the test. The test will fail if the result is not Ok(()). Sure, you have the additional boilerplate of the return type annotation and the final Ok(()), but the test logic itself reads nicer, I think.

simias 6y ago

Completely agree. I used to create my own error type(s) manually and implement the various conversions for 3rd party crates and it was quite a lot of boilerplate but with anyhow (for applications where you don't really care about strict error types) and thiserror (when you need to be a little more thorough). Actually that's effectively TFA's solution, if they had used thiserror/anyhow from the start there might not have been an issue to begin with. Admittedly it took me a while to find these crates since they're not part of std. Maybe the community should come together to create a curated list of third party crates that should probably be known by all Rust devs? Crates like thiserror, anyhow, rand, serde, clap and other "de-facto standard" crates?

wronghorse 6y ago
This is really interesting because I recently found the anyhow crate and I was wondering why it's not mentioned anywhere else. Definitely feels like useful information that a newly minted Rust dev could make use of.
- simias 6y ago
  Indeed. I wish I learned about it earlier myself, it would've saved me some boilerplate in the past.

nwellnhof 6y ago

> Rust error handling is great for reliable systems. Last time I checked, Rust couldn't even catch malloc failures.

wizzwizz4 6y ago
To be fair, these days malloc doesn't fail; your program crashes when it tries to use the memory, and there's nothing you can do about it. (But I agree that this is a problem with Rust's alloc system.)
- folmar 6y ago
  It can, it just doesn't when the 0physical memory is exhausted, but there are other conditions $ ulimit -v 10240 < printf("%p\n", malloc(1024*1024*128)); > nil