4 ms·

The issue is this: Things will go wrong. Some subset of things that can go wrong are things you want to do something about (e.g. file doesn't exist -- maybe pr

The issue is this: Things will go wrong. Some subset of things that can go wrong are things you want to do something about (e.g. file doesn't exist -- maybe prompt the user for a different file). The remainder are things you don't want to deal with (e.g. out of memory -- in most cases this is very rare so you're ok to just crash). You want to arrange your program in such a way that you must deal with the errors you want to deal with. Your code won't compile if you don't. That is what this technique brings. More here (though you probably won't understand many of the terms if you haven't used a modern FP-inspired language before): http://underscore.io/blog/posts/2015/02/23/designing-fail-fast-error-handling.html http://underscore.io/blog/posts/2015/02/23/designing-fail-fa...

wvenable 11y ago
> You want to arrange your program in such a way that you must deal with the errors you want to deal with. Which would be fine but there is no way to do that without also having being forced to deal with the infinite errors you don't want to deal with.
- kibwen 11y ago
  If you don't want to deal with an error then you unwrap it, which will terminate your program just as well as an unhandled exception would. The salient difference is that you can't accidentally unwrap something, whereas you can accidentally forget to handle an exception.
  - wvenable 11y ago
    The set of exceptions that can be handled is vanishingly small. With exceptions you should be catching exceptions very infrequently and in key places. Talking about accidentally forgetting to handle an exception at a method-call site completely missed the point. That's not how one should code or think about coding when using exceptions.
- noelwelsh 11y ago
  This is false. I use the pattern in the linked blog post everyday so that my code must deal with the errors I want to deal with and can ignore the rest.
  - wvenable 11y ago
    Code littered with try! macros does the same thing as propagating exceptions but you have to be explicit at every call. You have put error handling code literally everywhere and then just achieve the same result that exceptions do automatically. I understand Rust's motivation for handling errors this way and it makes sense for the type of language it is. But in terms of computing science, it's a step back into the past. Just like manually managing memory.

wvenable 11y ago

> You want to arrange your program in such a way that you must deal with the errors you want to deal with. Which would be fine but there is no way to do that without also having being forced to deal with the infinite errors you don't want to deal with.

kibwen 11y ago
If you don't want to deal with an error then you unwrap it, which will terminate your program just as well as an unhandled exception would. The salient difference is that you can't accidentally unwrap something, whereas you can accidentally forget to handle an exception.
- wvenable 11y ago
  The set of exceptions that can be handled is vanishingly small. With exceptions you should be catching exceptions very infrequently and in key places. Talking about accidentally forgetting to handle an exception at a method-call site completely missed the point. That's not how one should code or think about coding when using exceptions.
noelwelsh 11y ago
This is false. I use the pattern in the linked blog post everyday so that my code must deal with the errors I want to deal with and can ignore the rest.
- wvenable 11y ago
  Code littered with try! macros does the same thing as propagating exceptions but you have to be explicit at every call. You have put error handling code literally everywhere and then just achieve the same result that exceptions do automatically. I understand Rust's motivation for handling errors this way and it makes sense for the type of language it is. But in terms of computing science, it's a step back into the past. Just like manually managing memory.