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.
However, repetition can introduce bugs, too, for example a very common mistake is to write this:
instead of this: 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.