I think he meant that it changed the nature of error handling, and thus changed the way developers think about bugs and the way we encounter them. Errors are returned from function calls, and callers are expected to check the value of that error. The error must be assigned into a variable (or intentionally ignored, which should never pass a code review), and then must be checked. This forces errors to be handled on the spot, or returned up the call stack intentionally, usually with some extra info/annotation. You don't get try/catch scenarios where an error is caught 10 calls above where it occurred.
Imagine writing Java, and wrapping every function call in a try/catch block, and inspecting the exception if one was caught, and then handling it or re-throwing it. That's kind of what we do in Go. There are no "unexpected errors" because it is clear where all errors originate and how they are to be handled.
Go2 will improve on this if err != nil syntax, possibly with some function-scoped error handler and a new language level handle/check concept. Check it out
Catching all exceptions is what we used to do in Java - using checked exceptions. It turns out that in many cases the caller cannot do anything sensible with most exceptions, except to let them bubble up to a higher layer. Eventually you reach a point where something can be done - rolling back and retrying a whole transaction, for example.
Forcing every intermediate layer in the call stack to catch and rethrow that exception (check and propagate an error code) sounds like a good thing for explicit error handling, but actually in practice introduces a lot of boilerplate code that just provides more opportunities for mistakes (like errors being silently swallowed, or logged multiple times creating confusing log files).
How many times in a code review do you see `if err != nil { return err }` and ask yourself if what it is doing is actually appropriate? Most people just mentally mask out that kind of boilerplate over time.
It's really easy to let exceptions raise and pass through in languages like Python. In Go you'll typically return and handle errors explicitly. This makes it easier to reason about potential failure modes and behaviors in some cases.
I think it removes bugs caused by the try/catch pattern which can make it very difficult to follow the path of execution. In a sense exceptions have the same issues as "goto".
It's not that they are inherently bad so much as it requiring discipline to stop things from getting out of hand, and that's just something you want to avoid in larger projects. If you need to be disciplined you might as well just check the return error value.
Exceptions seem less unstructured than "goto". With exceptions, at least everything is strictly nested.
And there's a new class of bugs: forgetting to check for an error. In Rust, the compiler won't let you forget. With exceptions, forgetting to handle an exception will result in a somewhat controlled termination process. In Go, execution will just continue in a bad state.
