4 ms·

> On the cost of some repetition here and there, it makes programs look very explicit, which helps readers to understand the code better, instead of wondering:

> On the cost of some repetition here and there, it makes programs look very explicit, which helps readers to understand the code better, instead of wondering: can the exception be thrown here or not? I don't get this. In practice, most functions end up having an error result by convention, so the answer to "can the exception be thrown here" is always "maybe", which is the same as the answer would be to any function call in a language with exceptions...

beefsack 9y ago
Also, even without exceptions, it's possible to have explicit error handling without so much boilerplate. Rust's `?` operator achieves the same thing as Go without filling your code with conditionals and return statements. I do appreciate the difficulty in balancing simplicity and verbosity, but there are a handful of cases in Go where I wish they added some complexity to make the code significantly more terse.
- 0xCMP 9y ago
  Adding some kind of optional into Go would make things much easier. It's a cleaner version of the same thing.
  - valuearb 9y ago
    Well, Lattner did propose adoption some of Go's concurrency models in Swift. Then you already have optionals, a faster garbage collector, and a much deeper language. https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9... You just don't have a big community building server tools and libraries around it yet.
    - hamandcheese 9y ago
      If swift had a better concurrency story I would be all over it. The general vibe I get though (as an iOS super noob) is that concurrency patterns were already established back in the ObjC days and there’s little incentive for Apple to change it. I sure hope I’m wrong!
xyzzy_plugh 9y ago
I think that misses the point -- explicit behavior is always more desirable than implicit behavior. I don't think most functions end up having an error result by convention -- many functions never return errors. Treating errors as values means the flow of control is linear and obvious to the reader. Operations happen in their expected order. Resource management becomes trivial. It also allows errors to naturally be more expressive. This appears to be a decent starting point to further enlightenment: https://davidnix.io/post/error-handling-in-go/ https://davidnix.io/post/error-handling-in-go/
- wvenable 9y ago
  > I don't think most functions end up having an error result by convention -- many functions never return errors. Only the most trivial functions don't have the possibility of error. And if a function doesn't have an error condition today doesn't mean it won't be changed to have one tomorrow. Java has ruined too many programmers on exceptions by making them checked and making you do a lot of unnecessary try/catch dancing. A program should only have a few key try/catch blocks in the places where recovery is possible and it should be only concerned with what it can recover from. This obsession with every error that any method can throw/return is entirely the wrong way to deal with exceptional conditions. Therefore, error handling in Go is as backwards as it comes.
  - lpghatguy 9y ago
    If your function doesn't throw errors now, but does in the future, that's an API breakage. Using `Result` types as your only mode of error handling makes that API contract explicit.
    - wvenable 9y ago
      Two of the fundamental principles of object-oriented programming are encapsulation and polymorphism; the idea that exceptional errors are part of the API contract is completely at odds with idea of isolating the implementation of different components. A component that calculates exchange rates might use a file today and a network service tomorrow. My code should not have to care how every single component is implemented all the way down through the entire code base and every 3rd party library. And if my code is designed to restart high-level operations due to temporary network exceptions then it will be robust without knowing which components use the network now or in the future. Properly typed `result` types and checked exceptions make implementation details explicit. I don't want that part of the API contract.
pc2g4d 9y ago
I think they mean that they know in advance whether to write error handling code or not, not whether or not an exception will actually be thrown at runtime. The answer to _that_ is always maybe, but the answer to the former depends on the function.
- Will_Parker 9y ago
  Another irony here is, you're eventually going to have to worry about panics anyway.

beefsack 9y ago

Also, even without exceptions, it's possible to have explicit error handling without so much boilerplate. Rust's `?` operator achieves the same thing as Go without filling your code with conditionals and return statements. I do appreciate the difficulty in balancing simplicity and verbosity, but there are a handful of cases in Go where I wish they added some complexity to make the code significantly more terse.

0xCMP 9y ago
Adding some kind of optional into Go would make things much easier. It's a cleaner version of the same thing.
- valuearb 9y ago
  Well, Lattner did propose adoption some of Go's concurrency models in Swift. Then you already have optionals, a faster garbage collector, and a much deeper language. https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9... You just don't have a big community building server tools and libraries around it yet.
  - hamandcheese 9y ago
    If swift had a better concurrency story I would be all over it. The general vibe I get though (as an iOS super noob) is that concurrency patterns were already established back in the ObjC days and there’s little incentive for Apple to change it. I sure hope I’m wrong!

xyzzy_plugh 9y ago

I think that misses the point -- explicit behavior is always more desirable than implicit behavior. I don't think most functions end up having an error result by convention -- many functions never return errors. Treating errors as values means the flow of control is linear and obvious to the reader. Operations happen in their expected order. Resource management becomes trivial. It also allows errors to naturally be more expressive. This appears to be a decent starting point to further enlightenment: https://davidnix.io/post/error-handling-in-go/ https://davidnix.io/post/error-handling-in-go/

wvenable 9y ago
> I don't think most functions end up having an error result by convention -- many functions never return errors. Only the most trivial functions don't have the possibility of error. And if a function doesn't have an error condition today doesn't mean it won't be changed to have one tomorrow. Java has ruined too many programmers on exceptions by making them checked and making you do a lot of unnecessary try/catch dancing. A program should only have a few key try/catch blocks in the places where recovery is possible and it should be only concerned with what it can recover from. This obsession with every error that any method can throw/return is entirely the wrong way to deal with exceptional conditions. Therefore, error handling in Go is as backwards as it comes.
- lpghatguy 9y ago
  If your function doesn't throw errors now, but does in the future, that's an API breakage. Using `Result` types as your only mode of error handling makes that API contract explicit.
  - wvenable 9y ago
    Two of the fundamental principles of object-oriented programming are encapsulation and polymorphism; the idea that exceptional errors are part of the API contract is completely at odds with idea of isolating the implementation of different components. A component that calculates exchange rates might use a file today and a network service tomorrow. My code should not have to care how every single component is implemented all the way down through the entire code base and every 3rd party library. And if my code is designed to restart high-level operations due to temporary network exceptions then it will be robust without knowing which components use the network now or in the future. Properly typed `result` types and checked exceptions make implementation details explicit. I don't want that part of the API contract.

pc2g4d 9y ago

I think they mean that they know in advance whether to write error handling code or not, not whether or not an exception will actually be thrown at runtime. The answer to _that_ is always maybe, but the answer to the former depends on the function.

Will_Parker 9y ago
Another irony here is, you're eventually going to have to worry about panics anyway.