yes, that's exactly how I also think about Go's error handling. It was always praised the in the early days but it becomes more and more obvious that it's not a good way of handling errors, let alone reading code full of error returns and if err
I see this argument a lot, but error handling is also code that you probably want to read. Especially if you are debugging a problem. My experience is that exposing the error handling logic makes this easier. But I also like John Ousterhout’s suggestion to define errors out of existence where possible (A Philosophy of Software Design). But that requires more thinking than some developers like to deal with.
