8 ms·

Rust's aversion to exceptions is exactly like Go's aversion to generics - a strongly held position that doesn't actually make anyone's life easier.

jimktrains2 9y ago
I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked exceptions in java, there are still exceptions that aren't checked, and the syntax for the checking becomes monstrous.
- vbezhenar 9y ago
  Implicit return codes (e.g. return int, -1 means error, 0+ means OK) are equivalent to unchecked exceptions. Explicit return codes, where you must process them or compiler will yell at you are equivalent to checked exceptions. I think, that checked exceptions are a good idea, but they must be improved. E.g. Rust have syntax for almost implicit converting one error to another and return it; checked exceptions could use similar approach, so you can declare another exception in your "throws" cause and compiler'll generate conversion code for any unhandled checked exception. Anyway for me exceptions are way easier to work with, than return codes.
  - jimktrains2 9y ago
    Yes, exceptions are better than return codes, but I would argue Result types are better than exceptions. Checked exceptions in Java have their issues. Exceptions in C++ are odd beasts (though that's getting better, they're still not checked and therefor basically anything that isn't noexcept can throw them (oh wait! noexcept can throw! it just crashes immediately)).
  - quicknir 9y ago
    That equivalence is false. An unhandled exception bubbles up. An unhandled return code is ignored. This was exactly one of the biggest arguments against return codes.
- jeremyjh 9y ago
  The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it will ever be used in these contexts to begin with.
  - jimktrains2 9y ago
    I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, not the break that exceptions provide. Third, it's useful for more than just "Exceptions". Coupled with Optional types, it provides a more expressive way of not-hapy-path-code where exceptions just feel heavy handed. For instance https://docs.python.org/3/library/stdtypes.html https://docs.python.org/3/library/stdtypes.html d[key] Return the item of d with key key. Raises a KeyError if key is not in the map. The key not existing isn't really exceptional. A proper optional, union, or result type handles this case much more easily. In sum, I think the expressibility of Result and Option, along with a more natural flow for handling them will make working around them less tempting/viable/easy to pass over in a code review.
    - jeremyjh 9y ago
      You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first place. I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.
grahn 9y ago
The Go people don't have an aversion for generics, just a very conservative approach to adding language features. To quote their FAQ: "Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do."[1] [1] http://golang-jp.org/doc/faq#generics http://golang-jp.org/doc/faq#generics
- mikebenfield 9y ago
  Sounds like an aversion to me. By the time Go was developed, there was no doubt in my mind that generics (or some kind of polymorphism along those lines) were an essential feature for any new statically typed programming language. The fact that Go's developers "don't feel an urgency for them" to me makes it sound like they are living in the 1980s.
  - burntsushi 9y ago
    > were an essential feature Do you mean, "this feature is required for me to write code in that language"? Or do you mean, "this feature is required for any project in the language to flourish"? If the former, why do you think your preferences generalize? If the latter, how do you explain the large number of successful Go projects? Are we all stuck in the 1980s? And if so, what does that even mean?
    - mikebenfield 9y ago
      Well, at the time I would have thought it was required for the language to become widely used. But since that's clearly not true I suppose I have to downgrade that statement to say it's required for me to write code in the langauge and not feel like I'm constantly banging my head against a wall. Frankly, yeah, I think Go programmers are kind of stuck in the 1980s in some respects. This isn't something I'm completely clear about, but I feel like Go's developers are biased against anything that smells at all academic. So for instance they didn't want to implement a super fancy, cutting-edge type system. Which is somewhat understandable... but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C. I do not understand this mentality.
marcosdumay 9y ago
Monads are a superior form of error handling than exceptions... The only problem is that AFAIK (but I'm still learning it) Rust is missing something equivalent to Haskell's do notation.
- burntsushi 9y ago
  > The only problem is that AFAIK (but I'm still learning it) Rust is missing something equivalent to Haskell's do notation. Rust has essentially specialized do-notation for error handling called the `try!` macro, or more recently, `?`. (`try!` and `?` are exactly equivalent in today's Rust.) Actually, it does just a bit more than standard do-notation would: it also tries to convert your error value at the call site to the error type expected by the return type of the current function. The problems posed in the OP are pedagogical ones IMO that I hope can be solved. I think the current resource on error handling in the book is good for folks who really want to dive in and figure out the complete story, but it's bad for folks who just want to write code that works without spending a couple hours doing a deep dive. So I think there's room for more targeted pedagogy here.
- hota_mazi 9y ago
  > Monads are a superior form of error handling than exceptions No, they're not, not by a long shot. As soon as you start having multiple monads returned by functions and you need to combine them, you need to introduce monad transformers and your code turns into a giant untractactable spaghetti mess. Exceptions have issues but they are the sanest way to handle errors today.
  - marcosdumay 9y ago
    Well, if you start doing more with monads than error handling, you will have complex interactions between them. They are still superior for error handling, exceptions would have a more complex interaction with them.
  - placeybordeaux 9y ago
    I honestly found error codes in go to be pretty pragmatic. You pay a small cost on the writing side, but it's very clear and straight forward.
MichaelGG 9y ago
Exception safety is complicated. I didn't believe this, having only used exceptions in higher-level languages, but enough time talking to Rust folks and I get it now. And even in C#, I know I'm getting things wrong here and there with exceptions, but it doesn't have the same impact (safety/mem leaks) due to being GC'd and memory safe.
pcwalton 9y ago
We nearly had a hostile language fork over mandatory unwinding. It is not something that the language team decided and refuses to acknowledge. Rather, we had to respond to the demands of our embedded users.
- cousin_it 9y ago
  Fair enough.

jimktrains2 9y ago

I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked exceptions in java, there are still exceptions that aren't checked, and the syntax for the checking becomes monstrous.

vbezhenar 9y ago
Implicit return codes (e.g. return int, -1 means error, 0+ means OK) are equivalent to unchecked exceptions. Explicit return codes, where you must process them or compiler will yell at you are equivalent to checked exceptions. I think, that checked exceptions are a good idea, but they must be improved. E.g. Rust have syntax for almost implicit converting one error to another and return it; checked exceptions could use similar approach, so you can declare another exception in your "throws" cause and compiler'll generate conversion code for any unhandled checked exception. Anyway for me exceptions are way easier to work with, than return codes.
- jimktrains2 9y ago
  Yes, exceptions are better than return codes, but I would argue Result types are better than exceptions. Checked exceptions in Java have their issues. Exceptions in C++ are odd beasts (though that's getting better, they're still not checked and therefor basically anything that isn't noexcept can throw them (oh wait! noexcept can throw! it just crashes immediately)).
- quicknir 9y ago
  That equivalence is false. An unhandled exception bubbles up. An unhandled return code is ignored. This was exactly one of the biggest arguments against return codes.
jeremyjh 9y ago
The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack. I don't see how the Rust approach would avoid this fate but I doubt it will ever be used in these contexts to begin with.
- jimktrains2 9y ago
  I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions. First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well. Second, it feels more like a natural code-flow, not the break that exceptions provide. Third, it's useful for more than just "Exceptions". Coupled with Optional types, it provides a more expressive way of not-hapy-path-code where exceptions just feel heavy handed. For instance https://docs.python.org/3/library/stdtypes.html https://docs.python.org/3/library/stdtypes.html d[key] Return the item of d with key key. Raises a KeyError if key is not in the map. The key not existing isn't really exceptional. A proper optional, union, or result type handles this case much more easily. In sum, I think the expressibility of Result and Option, along with a more natural flow for handling them will make working around them less tempting/viable/easy to pass over in a code review.
  - jeremyjh 9y ago
    You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first place. I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.

grahn 9y ago

The Go people don't have an aversion for generics, just a very conservative approach to adding language features. To quote their FAQ: "Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do."[1] [1] http://golang-jp.org/doc/faq#generics http://golang-jp.org/doc/faq#generics

mikebenfield 9y ago
Sounds like an aversion to me. By the time Go was developed, there was no doubt in my mind that generics (or some kind of polymorphism along those lines) were an essential feature for any new statically typed programming language. The fact that Go's developers "don't feel an urgency for them" to me makes it sound like they are living in the 1980s.
- burntsushi 9y ago
  > were an essential feature Do you mean, "this feature is required for me to write code in that language"? Or do you mean, "this feature is required for any project in the language to flourish"? If the former, why do you think your preferences generalize? If the latter, how do you explain the large number of successful Go projects? Are we all stuck in the 1980s? And if so, what does that even mean?
  - mikebenfield 9y ago
    Well, at the time I would have thought it was required for the language to become widely used. But since that's clearly not true I suppose I have to downgrade that statement to say it's required for me to write code in the langauge and not feel like I'm constantly banging my head against a wall. Frankly, yeah, I think Go programmers are kind of stuck in the 1980s in some respects. This isn't something I'm completely clear about, but I feel like Go's developers are biased against anything that smells at all academic. So for instance they didn't want to implement a super fancy, cutting-edge type system. Which is somewhat understandable... but as a result they ignored 30 years of programming langauge research and implemented a primitive type system that basically provides nothing over C. I do not understand this mentality.

marcosdumay 9y ago

Monads are a superior form of error handling than exceptions... The only problem is that AFAIK (but I'm still learning it) Rust is missing something equivalent to Haskell's do notation.

burntsushi 9y ago
> The only problem is that AFAIK (but I'm still learning it) Rust is missing something equivalent to Haskell's do notation. Rust has essentially specialized do-notation for error handling called the `try!` macro, or more recently, `?`. (`try!` and `?` are exactly equivalent in today's Rust.) Actually, it does just a bit more than standard do-notation would: it also tries to convert your error value at the call site to the error type expected by the return type of the current function. The problems posed in the OP are pedagogical ones IMO that I hope can be solved. I think the current resource on error handling in the book is good for folks who really want to dive in and figure out the complete story, but it's bad for folks who just want to write code that works without spending a couple hours doing a deep dive. So I think there's room for more targeted pedagogy here.
hota_mazi 9y ago
> Monads are a superior form of error handling than exceptions No, they're not, not by a long shot. As soon as you start having multiple monads returned by functions and you need to combine them, you need to introduce monad transformers and your code turns into a giant untractactable spaghetti mess. Exceptions have issues but they are the sanest way to handle errors today.
- marcosdumay 9y ago
  Well, if you start doing more with monads than error handling, you will have complex interactions between them. They are still superior for error handling, exceptions would have a more complex interaction with them.
- placeybordeaux 9y ago
  I honestly found error codes in go to be pretty pragmatic. You pay a small cost on the writing side, but it's very clear and straight forward.

MichaelGG 9y ago

Exception safety is complicated. I didn't believe this, having only used exceptions in higher-level languages, but enough time talking to Rust folks and I get it now. And even in C#, I know I'm getting things wrong here and there with exceptions, but it doesn't have the same impact (safety/mem leaks) due to being GC'd and memory safe.

pcwalton 9y ago

We nearly had a hostile language fork over mandatory unwinding. It is not something that the language team decided and refuses to acknowledge. Rather, we had to respond to the demands of our embedded users.

cousin_it 9y ago
Fair enough.