Errors in Go: From denial to acceptance
I’m sorry but to me this just looks like Stockholm syndrome all the way.<p>The approach suggested for Go 2 under bargaining is basically a reverse try-catch at best and a Visual Basic “on error goto” at worst.<p>Even in their own attempt to explain why try catch is bad they effectively admit it serves a common use-case: A common use-case not handled by Go no less.<p>This lacking also puts the burden on the programmer which will have to manually handle each and every error, by himself, everywhere, one by one.<p>Even worse are the priorities given in the language: checking for errors is cumbersome, while ignoring errors is easy.<p>I’m willing to be proven wrong, but my immediate guess is that this in general leads to more buggy code, not less.