[Cthulhu_]

Well yeah, but that's a situation that C() cannot predict; it's an unexpected error. 99% of Go's errors are expected errors that can and should be handled - you mention a network connection being down, that's an expected outcome when doing anything related to a network.

A memory allocation failure is unexpected, and more down to the OS than the application itself; that's where a panic is in order and a last moment "something serious has happened".

In theory, Java's exception handling is supposed to do the same; checked exceptions for expected errors, unchecked for left-field things.

Anyway that aside, Go's error handling could be better because unlike e.g. the Either pattern, you're not actually required to handle errors and using _ you can easily ignore them. Second, the code style and conventions seem to tell you to just re-use an `err` variable if there's multiple errors that can occur in a function (common in e.g. file handling), which opens up the way for accidentally not checking and handling an error.

[onionisafruit]

The convention is to reuse err after you’ve handled any previous non-nil values. That does leave room for forgetting a check. I’ve made that mistake many times, but the errcheck linter finds the mistake every time.

[marcus_holmes]

This is all true. But there are static checkers to find these issues, it's not a huge deal. Having the power to ignore the convention when I want to is good :)