Hacker News Reader

Comment by tupshin | Hacker News Reader

Trollish troll is trolling.

Rust has a myriad of ways to handle errors, and unwrap is the most blunt of those instruments as it explicitly converts handleable errors into panics.

Alternatives such as try!, unwrap_or(), and many others, should be your preferred options. I try to only use unwrap() in throwaway code and usually only in main functions.

The one thing rust doesn't let you do (at least without warnings), is to have unhandled errors.

Being forced to explicitly handle error conditions is a huge net win for any production code.

View on HN

> The one thing rust doesn't let you do (at least without warnings), is to have unhandled errors.

Sounds a bit like Java's checked exceptions, largely regarded as a failed experiment. What makes Rust's version better?

Alternately, it's like Haskell's monads, largely regarded as a workable solution.

I think the key difference between checked exceptions and Rust's monadic error handling is that it's very easy to just panic if you don't care about recovering from the error. In Java you have to write "try { ... } catch (IOException e) { throw new RuntimeException(e); }", which is very verbose, and it's a lot less code to just ignore the exception. In Rust it's just ".unwrap()".

Monads have become a borderline buzzword these days. You're obviously the expert on Rust here, but it feels like it would be sufficient to just call it errors-as-values.

That there are no unchecked exceptions.

How many other ways to handle errors are there besides the three you mentioned? Why not just default to panic then if you are going to have to type unwrap everywhere? Does typing that all over the place prevent you from having errors in production?

The whole thing is asinine. Its the worst part of programmer culture.

You can write unwrap in production, if you know that the error isn't supposed to happen. But Rust's error handling forces you to think about errors and how to handle them, by design. Rust's way is also much more efficient at runtime, because using stack unwinding to recover from every error would be slow in the cases where errors are an expected and normal part of operation.

Question 1: because it's the wrong default for robust code.

Question 2: no, you don't use unwrap in production.

Jesus. What would the 'correct' MIO production code look like without unwraps? Or is that a PhD research project, 'correctly' implementing this page of code for 'production'?

If this were not happening in main(), then the following would be one way of handling the errors.

  fn foo() -> Result<(),Error> {
      // Create an event loop
      let mut event_loop = try!(EventLoop::<(), u64>::new());
      let sender = event_loop.channel();
      for i in 0.. 5 {
          try!(sender.send(i));
      }
      // Start it
      try!(event_loop.run(&mut BearHandler(0));
  }

You can always use `map`, `and` and `and_then`.

Reply on news.ycombinator.com