> do you want to know when something bad can happen in your program, or don’t you?
No actually, I want to know when consequential errors that I can be responsible for happen.
I don't really care that reading a file could fail (and it can fail in such a variety of ways, there's like 3 dozen distinct errors that could be thrown!) because I can't do anything about that. But if there are errors that I could recover from, that I would care about.
Unfortunately while it's possible, very little code distinguishes between error kinds or returns custom errors in go, so your bet is usually parsing error messages, while in Python or rust you have the ability to handle errors that are relevant to you, and let irrelevant ones percolate away.
Go on the other hand encourages doing nothing except logging, because it's somewhere between difficult/unidiomatic and impossible (depending on the libraries your building on top of) to handle only certain kinds of errors.
As a concrete example, in that csv parsing code, how do you differentiate between a file not found, file too large, and lacking permissions to read it? The stack overflow consensus is that doing that is unidiomatic, and you should just print the error to the user, which means this is just boilerplate for an exception that will ultimately gracefully end processing and print an error/stacktrace to the user. A bunch more typing for precisely the same intent as you get for free in Python or Java.
No actually, I want to know when consequential errors that I can be responsible for happen.
I don't really care that reading a file could fail (and it can fail in such a variety of ways, there's like 3 dozen distinct errors that could be thrown!) because I can't do anything about that. But if there are errors that I could recover from, that I would care about.
Unfortunately while it's possible, very little code distinguishes between error kinds or returns custom errors in go, so your bet is usually parsing error messages, while in Python or rust you have the ability to handle errors that are relevant to you, and let irrelevant ones percolate away.
Go on the other hand encourages doing nothing except logging, because it's somewhere between difficult/unidiomatic and impossible (depending on the libraries your building on top of) to handle only certain kinds of errors.
As a concrete example, in that csv parsing code, how do you differentiate between a file not found, file too large, and lacking permissions to read it? The stack overflow consensus is that doing that is unidiomatic, and you should just print the error to the user, which means this is just boilerplate for an exception that will ultimately gracefully end processing and print an error/stacktrace to the user. A bunch more typing for precisely the same intent as you get for free in Python or Java.