package main
import "io/ioutil"
func main() {
data, err := ioutil.ReadFile("/etc/ttys")
...
println(string(data))
} f, err := os.Open("/etc/ttys")
if err != nil {
// handle `err` "f not found"
}
try:
f = open("/etc/ttys")
except IOError as err:
// handle `err` "f not found"
With Go you pretty much have to attach a conditional to many calls.
Your obsession with clean revision histories is another matter.
I think most people who are bothered by Go's error handling are really just bothered by cross-package panics not being idiomatic (and thank god they aren't).
I have no issue with an argument that a panic making it out of a library meant for general external use is usually a bad thing -- that's not a "reasonable use of exceptions".
But my own applications are deliberately structured so that most of the outer layers can safely assume most operations will just work, as inner layers, to which interaction with external libraries is largely confined, will log.Panic() if they don't. It's the right choice 90% or more of the time, and leaves us with shorter, cleaner code.
In any case, I severely dislike arguments based on whether something is "idiomatic" or not. It's one thing when you're talking about loops and switches, and something else entirely when you hit someone over the head with it on architectural matters, especially in a language this young.
No, but "is it worse than the very worst possible option" isn't a good standard to use.
>Compared to?
ADTs.
>Why is that?
Because you can use the value even when an error occurred. The type system should prevent this, as is trivially done in every language with ADTs.
In this case, when opening a file, you can go ahead and use the value and "ignore" the error. Go ahead a run either of the above examples. Notice tptacek explicitly ignores the error.
This argument comes up a lot in lieu of or during talk of Generics, so it'd be best for me to defer to those discussions. Unless you or the OP have examples of hating `err` handling not yet described here, opening / reading a file in Go doesn't strike me as a place to take jabs at how errors are handled in Go.