withoutboats/fehler
github.com
Rust doesn't have exceptions. Contribute to withoutboats/fehler development by creating an account on GitHub.
  • Dessalines@lemmy.ml
    4·
    3 years ago

    This is mostly cosmetic, but I kinda like Result better in the example they gave:

    #[throws(i32)]
fn foo(x: bool) -> i32 {
    if x {
        0
    } else {
        throw!(1);
    }
}

fn bar(x: bool) -> Result<i32, i32> {
    if x {
        Ok(0)
    } else {
        Err(1)
    }
}

    The rust devs put a lot of thought into errors and compile time error checking, its pry just best to use their paradigms instead of using the throws methodology from java and wherever else that comes from.

  • pinknoise@lemmy.ml
    2·
    3 years ago

    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?

    • kevincox@lemmy.ml
      3·
      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)

  • Azure@lemmy.ml
    1·
    3 years ago

    I love it, I think it’s a definite step up in ergonomics. My only complaint is that with both it and async-trait being procedural macros they don’t compose well/at all together.