5 ms·

It's certainly not difficult to understand Go error handling. But it does take up quite a bit of real-estate. I think more importantly for me, it's too easy to

It's certainly not difficult to understand Go error handling. But it does take up quite a bit of real-estate. I think more importantly for me, it's too easy to forget an error check. Having primitives which make error checking painless and validated by the compiler would be nice.

usrbinbash 3y ago
> it's too easy to forget an error check. How? What exactly makes this "too easy"? In regards to a functions error returns, there are exactly two things a caller can do func foo() (int, error) { // foo code } // explicitely ignore the error foo() val, _ := foo() // handling the error val, err := foo() _, err := foo() If I do the latter, I cannot ignore `err`. If I do, the compiler yells at me because there is now an unused value in my code. If I do the former, then I made the conscious choice that the error doesn't matter to me. Yes, this goes for `foo()` as well, because Go makes it exceedingly clear that errors are just return values, and that call ignores all returns.
- VBprogrammer 3y ago
  Unless things have changed, if the return is only a single error value then it's possible to overlook capturing it.
randomdata 3y ago
> it's too easy to forget an error check. I never understood this. I do understand it is easy to forget to handle an error like it is easy to forget to handle a distance or temperature. Humans will make mistakes. But nobody laments about how they forget to handle distances or temperatures, or cry for special constructs to ensure that they don't screw up their distance and temperature handling. What is it about the word error that sends developers into a tizzy? Why would we want a solution that only works for errors and not for values of all kinds?
- vacuity 3y ago
  Because handling errors is important for complex programs. Whether errors-as-values or exceptions or aborts are the best option, being able to write a program that handles errors well makes it that much more robust. Don't want some weird behavior happening when the program should've noticed an error and dealt with it somehow.
  - randomdata 3y ago
    Handing values is important for all programs. You don't want some weird behaviour happening in any case. If you are writing a system that turns on a heater when the temperature falls below freezing, you're going to have a really bad time if you forget to handle the temperature. So, yes, it makes sense to have constructs that can help with that problem, but it would be weird to have such constructs only for what a human considers an error condition. You would want that for every case that needs to be handled. Otherwise you have to resort to testing, and if you accept that testing is good enough to ensure that you don't forget to check the temperature, then it also good enough to ensure that you have checked an error. There is nothing special about the error case. It's just another state like any other.
    - vacuity 3y ago
      Well, I think that's why a lot of people are disappointed that Go doesn't quite have sum types, because sum types do increase expressivity around values in general. That they improve error handling is just one application.
      - randomdata 3y ago
        There seems to be no consensus as to what sum types actually means, but the most popular definition I find in my travels is: Tagged unions. Which is funny as a sum is not a union, but anyway... Assuming you share in that definition, while Go might benefit from tagged unions in general, I'm not sure they actually help in any way with remember to handle errors. A union is just as easy to forget to handle as a single discriminate type. But perhaps you are of another sum type school? Perhaps one of the other sum type definitions are useful here?

usrbinbash 3y ago

> it's too easy to forget an error check. How? What exactly makes this "too easy"? In regards to a functions error returns, there are exactly two things a caller can do func foo() (int, error) { // foo code } // explicitely ignore the error foo() val, _ := foo() // handling the error val, err := foo() _, err := foo() If I do the latter, I cannot ignore `err`. If I do, the compiler yells at me because there is now an unused value in my code. If I do the former, then I made the conscious choice that the error doesn't matter to me. Yes, this goes for `foo()` as well, because Go makes it exceedingly clear that errors are just return values, and that call ignores all returns.

VBprogrammer 3y ago
Unless things have changed, if the return is only a single error value then it's possible to overlook capturing it.

randomdata 3y ago

> it's too easy to forget an error check. I never understood this. I do understand it is easy to forget to handle an error like it is easy to forget to handle a distance or temperature. Humans will make mistakes. But nobody laments about how they forget to handle distances or temperatures, or cry for special constructs to ensure that they don't screw up their distance and temperature handling. What is it about the word error that sends developers into a tizzy? Why would we want a solution that only works for errors and not for values of all kinds?

vacuity 3y ago
Because handling errors is important for complex programs. Whether errors-as-values or exceptions or aborts are the best option, being able to write a program that handles errors well makes it that much more robust. Don't want some weird behavior happening when the program should've noticed an error and dealt with it somehow.
- randomdata 3y ago
  Handing values is important for all programs. You don't want some weird behaviour happening in any case. If you are writing a system that turns on a heater when the temperature falls below freezing, you're going to have a really bad time if you forget to handle the temperature. So, yes, it makes sense to have constructs that can help with that problem, but it would be weird to have such constructs only for what a human considers an error condition. You would want that for every case that needs to be handled. Otherwise you have to resort to testing, and if you accept that testing is good enough to ensure that you don't forget to check the temperature, then it also good enough to ensure that you have checked an error. There is nothing special about the error case. It's just another state like any other.
  - vacuity 3y ago
    Well, I think that's why a lot of people are disappointed that Go doesn't quite have sum types, because sum types do increase expressivity around values in general. That they improve error handling is just one application.
    - randomdata 3y ago
      There seems to be no consensus as to what sum types actually means, but the most popular definition I find in my travels is: Tagged unions. Which is funny as a sum is not a union, but anyway... Assuming you share in that definition, while Go might benefit from tagged unions in general, I'm not sure they actually help in any way with remember to handle errors. A union is just as easy to forget to handle as a single discriminate type. But perhaps you are of another sum type school? Perhaps one of the other sum type definitions are useful here?