Go Error Handling
Discussions debate the pros and cons of Go's explicit error handling via return values, criticizing its verbosity and repetitiveness while defenders praise its reliability and explicitness compared to exceptions in other languages.
Activity Over Time
Top Contributors
Keywords
Sample Comments
That sounds incredibly ignorant to me.If this is the first language you've used where you give that sort of attention to errors, you must not have used and learned from the terrible mistakes of C, which constantly returns errors which are not required to be handled, just like go.Heck, you must not have learned from bash where every second line is "if [[ $? != 0 ]]" or you just did set -e and fail hard.For me, the problem with Go's errors isn't even the lines the
Nope. Error handling in Go is still tedious.
I'm not sure error handling in Go is really explicit. Go checks that you assign an error and usually handle it, but it doesn't check that you handle all values of the error. If a function suddenly returns a new error value, the compiler won't help you here. This is like in language with unchecked exceptions, you have to read everything carefully.
I agree - I find Go's error handling encourages subtle bugs.
Go has error handling, it doesn't have exceptions for non-exceptional error cases.
Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.
returning errors doesn't have to have cluttered code. Just because Go messed it up doesn't mean it's bad.
By "error handling" in Go you mean "if err == nil" repeating every five lines throughout the codebase?
I am a full time developer in go. I feel the lack of good error handling every time I write a function call and then have to use the same if statement to check its result.
Go calls it "errors are values", but readability is poor when every error must be handled many times instead of implicitly returning to callers.