Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's all the same stuff, man. Rust just:

* makes you be explicit about call sites which throw

* makes it easy to reify fallible computation (so it can be stored in e.g. a Future)

For instance:

    fn foo() -> Result<Value, IoError> {
      let x = a()?;
      let _ = b();
      if someCondition {
        return Err(IoError::Whatever)
      }
      return c(x).unwrap();
    }

is just

    Value foo() throws IOException {
      x = a();
      try {
        b();
      } catch(Exception e) { /* TODO: ERROR HANDLING? */ }
      if (someCondition) {
        throw new IOException();
      }
      try {
        return c(x);
      } catch(Exception e) { abort(); }
    }
This is made especially clear by Swift's model which is pretty much exactly the same as Rust's, but makes it look like exceptions:

    // RIP typed errors
    func foo() -> Value throws {
      let x = try a() // "rethrow"
      try? b()
      if someCondition {
        throw "Oh No IO!"
      }
      return try! c(x)
    }


It is the same stuff, exactly why errors should be values with some sugar for using them instead of a crazy parallel universe. :-)


You're forgetting about language pads and shenanigans.


Unwinding is an implementation of exceptions. You can implement them as returns, or, in the case of Swift, passing in a pointer for the Error type.


Okay that's fair. I usually equate them because every language I've ever used has implemented them with unwinding.


... landing pads. not language pads. Sheesh!


You should add language pads to your sick sleeve. Never4get.


Your Rust code has a compiler warning - you've ignored the result of b() which is returning a Result which must be handled.


No, `let _ = x` is the official way to ignore a value explicitly. The lint ignores it.

(My code does have an error because I forgot to wrap the result in Ok)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: