4 ms·
> 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 does
by 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 agoRelying on "convention and code review" is still leaving it up to the programmer(s).
- preseinger 5y agoOf 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 agoDidn'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 agoRelying 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 agoDefering 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 agoI 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