I think they missed the point of Go's convention. It's designed to force people to handle the damn error as near to the call as possible.<p>I've seen way too many programs with a single exception handler right at the base of the program, that just goes "whoops, something bad happened, bye!". I've even seen this anti-pattern used with Go's panic-recover mechanism.<p>It's an interesting find though, that the actual performance cost for checking the error return is random, variable, and small. Good to know :)
As a famous software philosopher said (I think it was Uriel): errors are wrong.<p>Or, to put it more clearly: there are no errors, only conditions that you dislike. It's better to not burden your programming with your emotional shortcomings, and treat all conditions that you may encounter on an equal footing.<p>You try to open a file; the file may or may not exist, and both cases are equally likely and you get to decide what your program does in each case. No need to attach an emotionally charged label like "error" in one of the two cases of the conditional. Or worse, as some emotional fanatics do, to bend an otherwise clean programming language by adding features (e.g., exceptions) that help support your sentimental disposition.
The one item I'd really contend is where it says it "makes it easier to ... maintain over time".<p>That might be true for smaller code bases (tracking down exceptions generated from libraries called from libraries, fun!), or code bases where you don't use closed external libraries (that can generate unknowable exceptions), or you use only synchronous code (because asynchronous exceptions wind up jumping to fishkill, welcome to distributed systems (logically, physically or chronologically distributed)).<p>[EDIT] fixed thinko
Are they going to do this again after Go has switched to a register-based calling convention? <a href="https://go.googlesource.com/proposal/+/refs/changes/78/248178/1/design/40724-register-calling.md" rel="nofollow">https://go.googlesource.com/proposal/+/refs/changes/78/24817...</a>
FYI these results were presented at the Go Systems Conf SF last December: <a href="https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s" rel="nofollow">https://www.youtube.com/watch?v=inrqE0Grgk0&t=15126s</a>
Great article! As a performance dweeb, any information on how best to squeeze out a bit more performance is welcome. I might have to play with using panics in OjG (<a href="https://github.com/ohler55/ojg" rel="nofollow">https://github.com/ohler55/ojg</a>) and see if it gives a boost.