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.
However, repetition can introduce bugs, too, for example a very common mistake is to write this:
if err != nil {
return nil
}
if err != nil {
return err
}
This particular pattern is so common your brain often ends up completely skipping it and it's pretty hard to detect during code review.
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.
This is why we use linters, they can catch this kind of problem.
Rust, Haskell, Kotlin, yes. They force you to consider the error path.
Go makes it all too easy to just ignore errors and produce crashy code.