5 ms·

Go’s error handling is a strange this to praise considering it is entirely possible to ignore it without warning and the way to check error kinds was bolted on

Go’s error handling is a strange this to praise considering it is entirely possible to ignore it without warning and the way to check error kinds was bolted on through type assertions when errors are supposed to be values in Go. Error kinds are important especially in network programming when the error can be dozens of different things. Compare this to something like Rust or Haskell which force you to handle errors and their variants.

Thaxll 5y ago
Once again Rust does not force you to handle errors, you can ignore errors in Rust and it will compile. I can't say for Haskell but I doubt there is a language that forces you to handle error. let _ = openFile() Error ignored, it does compile, it will probably ends badly. As for network error: https://pkg.go.dev/net#OpError https://pkg.go.dev/net#OpError
Karrot_Kream 5y ago
Pretty much every form of Go tooling warns you when you ignore an error. If you only choose to run "go build", yes you can ignore it, but a simple "go vet" call and it'll be plain as day.
- azth 5y ago
  a, err := foo() // oops, unhandled error err = bar() if err != nil { ... } or fmt.Println("...") // oops, unhandled error or more insidiously err1 := foo() if err1 != nil { ... } err2 := bar() if err2 != nil { return err1 } // oops
  - Karrot_Kream 5y ago
    In the first and the last case, it seems obvious to me where the error is. An obvious code smell caught in review. The second error, yeah, but lots of languages don't enforce error handling around printing to stdout, and even though Rust does in theory, in practice everyone just unwraps it and moves on with their day.
    - azth 5y ago
      > but lots of languages don't enforce error handling around printing to stdout They do, they throw exceptions. > In the first and the last case, it seems obvious to me where the error is The last case is especially insidious. I've seen it in production several times now. Very easy to miss. Particularly when refactoring/copy pasting code (which you have to do a lot of in golang).
- kamaal 5y ago
  Certain things need to be available out of the box. The whole point of a programming language is to make the programmers life easier. By now decades of exposure to programming languages have made try/catch the standard way of working with errors. Forcing the programmer to guess issues, when the compiler/runtime could be doing it- IMO is just plain waste of human labor. And for even medium to large applications is a pointless exercise.

Thaxll 5y ago

Once again Rust does not force you to handle errors, you can ignore errors in Rust and it will compile. I can't say for Haskell but I doubt there is a language that forces you to handle error. let _ = openFile() Error ignored, it does compile, it will probably ends badly. As for network error: https://pkg.go.dev/net#OpError https://pkg.go.dev/net#OpError

Karrot_Kream 5y ago

Pretty much every form of Go tooling warns you when you ignore an error. If you only choose to run "go build", yes you can ignore it, but a simple "go vet" call and it'll be plain as day.

azth 5y ago
a, err := foo() // oops, unhandled error err = bar() if err != nil { ... } or fmt.Println("...") // oops, unhandled error or more insidiously err1 := foo() if err1 != nil { ... } err2 := bar() if err2 != nil { return err1 } // oops
- Karrot_Kream 5y ago
  In the first and the last case, it seems obvious to me where the error is. An obvious code smell caught in review. The second error, yeah, but lots of languages don't enforce error handling around printing to stdout, and even though Rust does in theory, in practice everyone just unwraps it and moves on with their day.
  - azth 5y ago
    > but lots of languages don't enforce error handling around printing to stdout They do, they throw exceptions. > In the first and the last case, it seems obvious to me where the error is The last case is especially insidious. I've seen it in production several times now. Very easy to miss. Particularly when refactoring/copy pasting code (which you have to do a lot of in golang).
kamaal 5y ago
Certain things need to be available out of the box. The whole point of a programming language is to make the programmers life easier. By now decades of exposure to programming languages have made try/catch the standard way of working with errors. Forcing the programmer to guess issues, when the compiler/runtime could be doing it- IMO is just plain waste of human labor. And for even medium to large applications is a pointless exercise.