4 ms·

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 r

by fierro 8y ago

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 https://dev.to/deanveloper/go-2-draft-error-handling-3loo https://dev.to/deanveloper/go-2-draft-error-handling-3loo https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

nmadden 8y ago
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.

by fierro 8y ago

nmadden 8y ago

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.