4 ms·

Programming is much more about understanding guarantees and curating the error path than it is about pulling a ticket from Jira and cranking out a happy path as

Programming is much more about understanding guarantees and curating the error path than it is about pulling a ticket from Jira and cranking out a happy path as agilely as you can. Error handling in other languages is like confetti. “Pop! Surprise!” A disorganized game of “52 pickup” using an under designed grab bag of control structures. No thanks.

rsj_hn 5y ago
Lack of adequate control structures, or for that matter, programming language support, is almost never the reason why code has inadequate error handling. The main reason is that developers often leave error handling as an afterthought because it distracts them from thinking about the main flow, and it's hard to program when you are constantly distracted. That's why you have overbroad exception handling and the consequent improper handling. The problem is with the brain, not with the programming language.
- preseinger 5y ago
  > developers often leave error handling as an afterthought because it distracts them from thinking about the main flow Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. Error handling _cannot be_ an afterthought -- this is the path to fragile, even broken, code. If a programmer can't adapt to this model, then they're gonna have a bad time with Go, because with Go it's non-optional!
  - plorkyeran 5y ago
    No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result.
    - preseinger 5y ago
      > No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result. The compiler is one way that language invariants can be expressed and enforced. But it's not the only one -- another "layer" is convention and code review. Concretely, something like v, _ := f(...) would _never_ pass code review at any reasonable organization. If you use the compiler to express invariants like this, then the language unavoidably becomes more complex. In some contexts, that makes sense! In others, it doesn't.
      - djur 5y ago
        Relying on "convention and code review" is still leaving it up to the programmer(s).
        preseinger 5y ago
        Of course! But software engineering in the large -- which is the domain that Go targets -- is ultimately not a technical domain, but a social one; the programmers who maintain the project are the ultimate authority. That's fine!
        super_flanker 5y ago
        Didn't you just claim: > Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. But it seems the go relies on a good code reviewer for error handling.
        preseinger 5y ago
        > Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, Yes... > and that you can't ignore the bad stuff as you program against the good stuff. No? I don't claim that -- at least in the sense that the compiler permits you to ignore errors if you want to. But that's not some death blow against the language. The compiler is one of many mechanisms that can be used to assert code quality.
  - erik_seaberg 5y ago
    The happy path is more important; it needs to be stated clearly and concisely, and reviewed and maintained more often. The error path is pretty much just “can we retry at some level, or just give up and tell the user nothing happened?” Even if you believe they are equally important, they are very different, and intermixing them makes each harder to follow.
    - preseinger 5y ago
      The happy path and the sad path are equally important. Shuffling the error path to some second-class zone is the root cause of a huge class of bugs and reliability issues. Error-handling code is equally important to business logic and inter-mixing them is necessary to write reliable software.
    - politician 5y ago
      They are different, and I'm biased towards a belief that error paths are more important, but I agree that intermixing them makes each harder to follow. This is a limitation of the medium - text, and different languages attempts at solving this limitation through more text (try/catch, on error, etc.) have mostly failed, IMO. Go's method of treating them like any other value is the most honest approach I've seen. No one freaks out when a FizzBuzz program does different things with different categories of integers.
mcronce 5y ago
It sounds like you're referring to exceptions. While I would take exceptions over the stringly-typed nightmare that is Go errors, you should know that there are far better error handling schemes out there.
- jeremyloy_wt 5y ago
  Go errors are not stringly typed. You can assert that the error itself, or any error it wraps, is it a particular type through errors.Is and As. If your past experience involved people comparing error.Error() strings I’m sorry. That’s awful and I can see why that would be a nightmare

rsj_hn 5y ago

Lack of adequate control structures, or for that matter, programming language support, is almost never the reason why code has inadequate error handling. The main reason is that developers often leave error handling as an afterthought because it distracts them from thinking about the main flow, and it's hard to program when you are constantly distracted. That's why you have overbroad exception handling and the consequent improper handling. The problem is with the brain, not with the programming language.

preseinger 5y ago
> developers often leave error handling as an afterthought because it distracts them from thinking about the main flow Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. Error handling _cannot be_ an afterthought -- this is the path to fragile, even broken, code. If a programmer can't adapt to this model, then they're gonna have a bad time with Go, because with Go it's non-optional!
- plorkyeran 5y ago
  No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result.
  - preseinger 5y ago
    > No, it really doesn't do that. Result types which force you to check for an error to get the non-error return value from a function, or Swift `try` which doesn't even let you call a function which may fail without writing some sort of error handling do that. Go leaves it up to the programmer to remember to check for errors, and lets you silently discard the error result. The compiler is one way that language invariants can be expressed and enforced. But it's not the only one -- another "layer" is convention and code review. Concretely, something like v, _ := f(...) would _never_ pass code review at any reasonable organization. If you use the compiler to express invariants like this, then the language unavoidably becomes more complex. In some contexts, that makes sense! In others, it doesn't.
    - djur 5y ago
      Relying on "convention and code review" is still leaving it up to the programmer(s).
      - preseinger 5y ago
        Of course! But software engineering in the large -- which is the domain that Go targets -- is ultimately not a technical domain, but a social one; the programmers who maintain the project are the ultimate authority. That's fine!
        super_flanker 5y ago
        Didn't you just claim: > Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, and that you can't ignore the bad stuff as you program against the good stuff. But it seems the go relies on a good code reviewer for error handling.
        preseinger 5y ago
        > Go asserts that "error handling" and "main flow" (a.k.a. "happy path") code paths are equivalent, Yes... > and that you can't ignore the bad stuff as you program against the good stuff. No? I don't claim that -- at least in the sense that the compiler permits you to ignore errors if you want to. But that's not some death blow against the language. The compiler is one of many mechanisms that can be used to assert code quality.
- erik_seaberg 5y ago
  The happy path is more important; it needs to be stated clearly and concisely, and reviewed and maintained more often. The error path is pretty much just “can we retry at some level, or just give up and tell the user nothing happened?” Even if you believe they are equally important, they are very different, and intermixing them makes each harder to follow.
  - preseinger 5y ago
    The happy path and the sad path are equally important. Shuffling the error path to some second-class zone is the root cause of a huge class of bugs and reliability issues. Error-handling code is equally important to business logic and inter-mixing them is necessary to write reliable software.
  - politician 5y ago
    They are different, and I'm biased towards a belief that error paths are more important, but I agree that intermixing them makes each harder to follow. This is a limitation of the medium - text, and different languages attempts at solving this limitation through more text (try/catch, on error, etc.) have mostly failed, IMO. Go's method of treating them like any other value is the most honest approach I've seen. No one freaks out when a FizzBuzz program does different things with different categories of integers.

mcronce 5y ago

It sounds like you're referring to exceptions. While I would take exceptions over the stringly-typed nightmare that is Go errors, you should know that there are far better error handling schemes out there.

jeremyloy_wt 5y ago
Go errors are not stringly typed. You can assert that the error itself, or any error it wraps, is it a particular type through errors.Is and As. If your past experience involved people comparing error.Error() strings I’m sorry. That’s awful and I can see why that would be a nightmare