That’s actually a brilliant assertion (sorry for the crap pun).
The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job.
When we were rewriting a module in our backend from PHP to Go, explicit error handling helped us find and fix bugs due to edge cases we weren't even aware of. The usual idiom in PHP was to just catch exceptions at the top level and show an error (I think that's what exception handling usually devolves to). Since in Go we were explicitly handling errors at every level in the chain, it forced us to reason about error conditions more carefully and made us more aware of potential edge cases, which didn't happen when we were writing in PHP because you only saw the happy path when looking at the code (i.e. little mention that something can go awry because exceptions are hidden from control flow). I remember in one such case, we found out you couldn't just bubble up an exception, you had to process it immediately, otherwise data could end up in an inconsistent state.
However, repetition can introduce bugs, too, for example a very common mistake is to write this:
if err != nil {
return nil
}
instead of this:
if err != nil {
return err
}
which is pretty serious because you essentially ignore the error.
This particular pattern is so common your brain often ends up completely skipping it and it's pretty hard to detect during code review.
Now I don't know how your PHP code was structured, but in my experience there usually three types of mistakes done with error handling in PHP code
1) not properly checking return values from standard library functions
2) not checking correct last error level function after use of standard library function, e.g. json_last_error(), curl_errno() etc
3) different handling of old style errors vs exceptions
This is an unfortunate legacy of PHP, it is messy and error prone.
I'm not a golang programmer but to my understanding is that the golang compiler does not enforce strict error handling, if a function changes its signature to start returning an error when it previously didn't is not something the compiler will warn about. This is unfortunate too.
I never really been a huge fan of exceptions either, but the good thing about exceptions is that they are not silent by default whereas return values can be ignored and therefore errors can missed.
What I'm trying to say is that we need stricter compilers.
My personal style of coding in PHP to avoid hidden bugs is to code in defensive style, where the unhappy path is as important as the happy path, combined with strict type handling where I try to use the type system to detect bugs.
Sure, Go makes you write code to do something in the case of an error - over and over again at every level in the chain. Which tends towards programmers putting in minimal effort each time, often meaning when some low level error occurs in the resulting application little information is forthcoming to the user as to why it's just aborted on them.
Good and bad error handling can be done in any language. I've not seen any evidence that Go apps and libraries generally do it better than those written in exception-enabled languages.
The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job.
Go makes them deal with it.