3 ms·

Another reason why "errors as values" error handling approach is superior. Compare let url = Url.parse(str)?; To let url; // invalid state try {

Another reason why "errors as values" error handling approach is superior. Compare let url = Url.parse(str)?; To let url; // invalid state try { url = new Url(str) } catch (e) { return ... }

Aeolun 2y ago
Where is your error handing logic in the top example? At the very least you’d need an if statement. This is comparing apples to oranges.
- CodesInChaos 2y ago
  It's using rust's ? operator. This operator evaluates to the value if the Result it's called represents success, and propagates the error if it represents failure. This assumes the calling function also returns a Result with an error that's convertible from the error the called function operated on. In many cases that's enough to handle an error. It's still not a great comparison, since implicitly letting the exception propagate is the closest correspondence in a language that uses exceptions for expected errors.
  - stouset 2y ago
    > implicitly letting the exception propagate It’s not really implicit though, is it? You’re explicitly asking the language to unwrap the result or propagate the error up out of the function. And the function return value explicitly encodes this, unlike exceptions which can happen anywhere for any reason at any time.
UncleMeat 2y ago
I think that this is sort of cheating. You could have a language that uses "?" as sugar for the more wordy try-catch-return code that you've written here. These examples aren't really showing the semantic difference between errors as values and thrown errors, which is the implicit propagation across multiple code locations.
- ivanjermakov 2y ago
  True, this might not be the best example, but it shows how much more control and flexibity former approach provides, given rich support fo Result type.
- mrkeen 2y ago
  I love cheating! > You could have a language that uses "?" as sugar for the more wordy try-catch-return code that you've written here. I do! (it's ">>=" though, not "?"). > These examples aren't really showing the semantic difference between errors as values and thrown errors, which is the implicit propagation across multiple code locations. Well here's where we can start to go in circles. I like errors as values, and I dislike Checked Exceptions. But I've seen others argue that Result and Checked Exceptions are completely equivalent. Different people have different ideas about what the semantics are.

Another reason why "errors as values" error handling approach is superior. Compare let url = Url.parse(str)?; To let url; // invalid state try { url = new Url(str) } catch (e) { return ... }

Aeolun 2y ago

Where is your error handing logic in the top example? At the very least you’d need an if statement. This is comparing apples to oranges.

CodesInChaos 2y ago
It's using rust's ? operator. This operator evaluates to the value if the Result it's called represents success, and propagates the error if it represents failure. This assumes the calling function also returns a Result with an error that's convertible from the error the called function operated on. In many cases that's enough to handle an error. It's still not a great comparison, since implicitly letting the exception propagate is the closest correspondence in a language that uses exceptions for expected errors.
- stouset 2y ago
  > implicitly letting the exception propagate It’s not really implicit though, is it? You’re explicitly asking the language to unwrap the result or propagate the error up out of the function. And the function return value explicitly encodes this, unlike exceptions which can happen anywhere for any reason at any time.

UncleMeat 2y ago

I think that this is sort of cheating. You could have a language that uses "?" as sugar for the more wordy try-catch-return code that you've written here. These examples aren't really showing the semantic difference between errors as values and thrown errors, which is the implicit propagation across multiple code locations.

ivanjermakov 2y ago
True, this might not be the best example, but it shows how much more control and flexibity former approach provides, given rich support fo Result type.
mrkeen 2y ago
I love cheating! > You could have a language that uses "?" as sugar for the more wordy try-catch-return code that you've written here. I do! (it's ">>=" though, not "?"). > These examples aren't really showing the semantic difference between errors as values and thrown errors, which is the implicit propagation across multiple code locations. Well here's where we can start to go in circles. I like errors as values, and I dislike Checked Exceptions. But I've seen others argue that Result and Checked Exceptions are completely equivalent. Different people have different ideas about what the semantics are.