5 ms·

> With explicit error handling, however deep your call stack is, you are relying on everything in that stack to have done the right thing with regards to error

> With explicit error handling, however deep your call stack is, you are relying on everything in that stack to have done the right thing with regards to error handling. With exceptions, you have to go out of your way to screw them up. I don't think I agree with this argument. In many languages, there's no obvious indicator that any given function may or may not raise / throw an exception. And even if it doesn't throw an exception today, it might tomorrow, and it's easy to forget to update all callers. Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error. And just like an intermediary library in Go can swallow the error, so can an intermediary library in an exception language catch and discard an exception. It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production. For context, I recently switched jobs from one where I wrote Python for 4.5 years to a job where I've been writing Go for about 5 months.

suresk 5y ago
> With Go making errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error. Right, but because `err` ends up getting re-used in so many cases, you can re-assign it and forget to do anything about it (which is what I've found in most cases where an error was inappropriately suppressed in Go). In most cases, simply bubbling up the error to something that will generically handle all errors is the right thing to do, and in the case of exceptions, even if you don't know about one, that is what will happen. I just sampled a handful of the top Golang repos on Github, and found very few cases of anything more than the standard `if err != nil; return nil, err' pattern that just bubbles the error up.
kortilla 5y ago
> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error. This is a bad thing because it’s not narrow. It’s like a language’s “catch” statement not allowing you to catch specific exceptions. Once someone has decided to throw away an error with the underscore assignment, all future errors the underlying might return are swallowed as well. In other words, it takes even more boilerplate to have narrower error exemptions than to have the generic exemption. > It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production. An error in go that is blindly returned all of the way up the stack has no difference with an uncaught exception.
anonymoushn 5y ago
Last time I wrote go you could write `doThingAndMaybeReturnErr()` without the `_ =`. Has this changed? The alternative is Zig or Rust's thing, where you still have explicit error handling but you don't repeat the same four lines all the time. This is maybe helpful because in Go one has to read those lines carefully to see if anything unexpected is happening.
- papaf 5y ago
  Linters such as golangci[1] which will warn if you ignore the return value. If you ever write Go again I highly recommend you look at golangci -- the security checks have been really helpful to me. [1] https://golangci-lint.run/ https://golangci-lint.run/
n_e 5y ago
> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error. LoadData(&data) Does this function return nothing or an error ?
- cy_hauser 5y ago
  It returns nothing or the compiler/linter/ide will tell you.
  - tsimionescu 5y ago
    Which compiler/linter/IDE is that? The Go compiler and linter certainly don't tell you: https://play.golang.org/p/k-eTs3dC_wK https://play.golang.org/p/k-eTs3dC_wK Note that Go playground also runs go vet, a static analysis tool.
    - cy_hauser 5y ago
      You're probably right. I use Goland and I just think of it as a natural extension to Go. I shouldn't.

suresk 5y ago

> With Go making errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error. Right, but because `err` ends up getting re-used in so many cases, you can re-assign it and forget to do anything about it (which is what I've found in most cases where an error was inappropriately suppressed in Go). In most cases, simply bubbling up the error to something that will generically handle all errors is the right thing to do, and in the case of exceptions, even if you don't know about one, that is what will happen. I just sampled a handful of the top Golang repos on Github, and found very few cases of anything more than the standard `if err != nil; return nil, err' pattern that just bubbles the error up.

kortilla 5y ago

> Since Go makes errors a return value you have to actively discard the result (by replacing it with a underscore, e.g. `res, _ := getResults()`) or take the time to handle the error. This is a bad thing because it’s not narrow. It’s like a language’s “catch” statement not allowing you to catch specific exceptions. Once someone has decided to throw away an error with the underscore assignment, all future errors the underlying might return are swallowed as well. In other words, it takes even more boilerplate to have narrower error exemptions than to have the generic exemption. > It seems to me that the result is more errors are properly handled in Go - because they are explicit - while uncaught exceptions often cause bugs that make it to production. An error in go that is blindly returned all of the way up the stack has no difference with an uncaught exception.

anonymoushn 5y ago

Last time I wrote go you could write `doThingAndMaybeReturnErr()` without the `_ =`. Has this changed? The alternative is Zig or Rust's thing, where you still have explicit error handling but you don't repeat the same four lines all the time. This is maybe helpful because in Go one has to read those lines carefully to see if anything unexpected is happening.

papaf 5y ago
Linters such as golangci[1] which will warn if you ignore the return value. If you ever write Go again I highly recommend you look at golangci -- the security checks have been really helpful to me. [1] https://golangci-lint.run/ https://golangci-lint.run/

n_e 5y ago

cy_hauser 5y ago
It returns nothing or the compiler/linter/ide will tell you.
- tsimionescu 5y ago
  Which compiler/linter/IDE is that? The Go compiler and linter certainly don't tell you: https://play.golang.org/p/k-eTs3dC_wK https://play.golang.org/p/k-eTs3dC_wK Note that Go playground also runs go vet, a static analysis tool.
  - cy_hauser 5y ago
    You're probably right. I use Goland and I just think of it as a natural extension to Go. I shouldn't.