4 ms·

> developers often leave error handling as an afterthought because it distracts them from thinking about the main flow Go asserts that "error handling" and "ma

> 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.
  - plorkyeran 5y ago
    Relying on code review to catch bugs is just leaving it up to a different programmer. Code review is wonderful, but expecting it to catch every occurrence of even just the categories of bugs easily caught by code review is wildly overoptimistic. Ignoring the second return value is also the easy case to catch. Ignoring an error-only return from a function doesn't produce a warning, and won't stand out in code review unless you adopt a standard of never writing void functions.
    - preseinger 5y ago
      > Relying on code review to catch bugs is just leaving it up to a different programmer. Go is a language for programminging "in the large" -- it explicitly defers a lot of stuff to layers "above" the compiler, like code review. If you don't buy that as legitimate that's fine!
      - plorkyeran 5y ago
        Defering things to other layers such as code review is the exact opposite of Go making it non-optional to explicitly handle errors. Idiomatic Go has developed very rigid patterns around how to handle errors specifically because if you want to write happy-path code which ignores errors the language itself does nothing to discourage you from doing that, and in fact makes that the easiest thing to do.
        preseinger 5y ago
        I really don't understand the point you're making. > if you want to write happy-path code which ignores errors . . . . . . it's obvious that's what you're doing in code review, and it's trivial to correct. Right? --- > if you want to write happy-path code which ignores error If you're doing this consistently you're going to have a lot of `value, _` i.e. underbar assignments in your code, and `_` isn't passing any code review process in any reasonable Go shop I've ever seen.
        plorkyeran 5y ago
- politician 5y ago
  Most (all?) languages, Go included, also leave it up to the programmer to remember to use the result value, so I can't really sympathize with your point.
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.

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.
- plorkyeran 5y ago
  Relying on code review to catch bugs is just leaving it up to a different programmer. Code review is wonderful, but expecting it to catch every occurrence of even just the categories of bugs easily caught by code review is wildly overoptimistic. Ignoring the second return value is also the easy case to catch. Ignoring an error-only return from a function doesn't produce a warning, and won't stand out in code review unless you adopt a standard of never writing void functions.
  - preseinger 5y ago
    > Relying on code review to catch bugs is just leaving it up to a different programmer. Go is a language for programminging "in the large" -- it explicitly defers a lot of stuff to layers "above" the compiler, like code review. If you don't buy that as legitimate that's fine!
    - plorkyeran 5y ago
      Defering things to other layers such as code review is the exact opposite of Go making it non-optional to explicitly handle errors. Idiomatic Go has developed very rigid patterns around how to handle errors specifically because if you want to write happy-path code which ignores errors the language itself does nothing to discourage you from doing that, and in fact makes that the easiest thing to do.
      - preseinger 5y ago
        I really don't understand the point you're making. > if you want to write happy-path code which ignores errors . . . . . . it's obvious that's what you're doing in code review, and it's trivial to correct. Right? --- > if you want to write happy-path code which ignores error If you're doing this consistently you're going to have a lot of `value, _` i.e. underbar assignments in your code, and `_` isn't passing any code review process in any reasonable Go shop I've ever seen.
        plorkyeran 5y ago
politician 5y ago
Most (all?) languages, Go included, also leave it up to the programmer to remember to use the result value, so I can't really sympathize with your point.

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.