this post was submitted on 08 Jul 2021
5 points (85.7% liked)

Rust Programming

8346 readers
15 users here now

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 2 points 3 years ago (1 children)

Whats the catch? (scnr)

Also I don't get it. Is this just a complicated way of writing Result<x, y> that saves you from wrapping return values in Ok?

[โ€“] [email protected] 3 points 3 years ago

Honestly this is temping for me. I frequently write functions that look like

fn foo() -> Result<(), Error> {
  do_bar()?;
  do_baz()?;
  Ok(())
}

But that Ok at the bottom is a little annoying. IIUC this lets you do:

#[fehler::throws]
fn foo() {
  do_bar()?;
  do_baz()?;
}

Which is a bit tidier.

If the error types match you can do

fn foo() -> Result<(), Error> {
  do_bar()?;
  do_baz()
}

But I find that a bit weird as it is asymmetrical for not much reason. And you lose the error conversion.

You also have complex examples where it gets a bit more awkward:

#[fehler::throws]
fn foo() -> u32 {
  match is_cool()? {
    true => do_foo()? + 1
    false => do_bar()? + 2
  }
}

This gets a bit more awkward if you need to decide where to put the Ok(...).

Overall I don't think it is a huge improvement, and I probably wouldn't add the dep and tag my functions to use it, but I see why it exists and it does make me wonder if a more implicit error handling syntax would make sense. (Maybe just implicitly converting the return value, but that could be surprising)