There's a difference between handling and propagating errors, most Go-code I've come across/written is pretty much using exceptions, but with 10x the noise and none of the convenience. Which might be fine, different languages have different goals; maybe simplicity is more important. But pretending it's somehow superior isn't fooling anyone.
An exception interrupts the entire flow of the program.
In go if something is truly exceptional then you can panic, but most of the time an error is non-fatal outside of a particular request (request not just related to a web request).
I agree, many people do errors incorrectly, but `try` does not make them suddenly correct either.
It's quite healthy for the community to have this discussion because this is introducing not just a new built-in function/expressiony thing, but also a means of flow control.
Unconditionally returning on errors all the way has exactly the same effect. Arguing that it's wrong isn't very constructive given that everyone seems to be doing it.
panic() is just another symptom of the same disease.
Exceptions are a very useful tool, and so is pattern matching and support for multiple returns. There is no one true way to handle errors.
Sure it is important but I have had functions looked like this
func foo() error {
a, err := bar()
if err != nil {
return err
}
b, err := baz(a)
if err != nil {
return err
}
...
}
In some code this error handeling is 3/4 of the function lines. Sure the error behavior is important but is it 3 times more important then the logic of what you are writing?
The if nill construct contributes to cognitive load and detracts from code plainly tells you what it does. And speaking from a practical perspective I’m going to be far more productive if 3 lines of commonly used code is turned into five characters.
Yes, that's how Go code looks, it has a rhythm of "do something, check for errors, do something, check for errors". This is a great idea, because checking for errors is explicit, and dealing with them is immediate.
After a while of working in Go, you get used to the rhythm and you stop noticing the "check for errors" part unless it does something different. You also notice when the check is missing.
And having most of your code devoted to error handling makes total sense. There are usually lots of errors states and only one "golden path" state - properly handling all the possible errors your code could generate will mean writing more error-handling code than logic code because there are more error states than non-error states it can get into.
All “try” does is allow you to write those three lines as five characters. In natural languages the more frequent used a word is the shorter that word tends to be. “Check for errors and return” is something that is frequently said in go, following from those principles it should be something that it short to write.
I see that, but it breaks the rhythm, and introduces an alternative syntax that makes it harder, not easier, to read. And code should be easier to read than to write, because we're going to read it way more than we write it.
Instead of "do something, check for errors, do something, check for errors" we would have "do something, check for errors, try something, do something, check for errors" (assuming not all errors are going to be "try"d, and some will need to be wrapped).
It stops being obvious when I've missed an error-check. That's bad.
