[vii]

Rob Pike wrote this about handling errors https://blog.golang.org/errors-are-values

This is like an option type but manually built.

Go is painful if you don't want to write high-quality heavily exercised production code. If you do, then you should be considering each error condition. Most code doesn't need to worry about error handling as it will run under close supervision on at most one machine over its lifetime. Go is a nuisance for that.

[aboodman]

Really the opposite is true.

If you want to know that you have handled every error path, Go is awful because there is no language or compiler support for it at all. Completeness has to be ensured manually, by inspection.

Check out Rust's error handling approach sometime for an example of a language that truly values complete and correct error handling. It is a joy.

===

The reality is that Go doesn't have better error handling because the language designers value the simplicity of Go's implementation more than the simplicity of its interface - a trait that directly flows from its unix roots [1].

This is a fine tradeoff, and the right one for many problems. Go has been extremely successful in large part because of this philosophy. But you should not kid yourself that this is somehow the Right Way to handle errors, just because it's what Go does. Because even Go's designers are actively trying to fix it [2].

[1] https://www.jwz.org/doc/worse-is-better.html

[2] https://github.com/golang/go/issues/32437

[apta]

> Go is painful if you don't want to write high-quality heavily exercised production code.

That's the excuse that the golang authors give. The fact of the matter, golang is also extremely annoying when writing "high quality production code". golang errors are error-prone, and on more than one occasion we've had instances where errors are mistakingly ignored. This is much worse than exceptions where they have to be explicitly swallowed, otherwise they'd automatically bubble up.