Error handling
Error handling in Go has been a polarizing issue. Frustrated with the repetitive error-handling boilerplate, many Go users in the community (including me) suggested improved error-handling mechanisms. Most of these proposals were actually error-passing improvements because, to be honest, errors are rarely handled. Rather, they are passed to the caller, sometimes wrapped with some contextual information.
A good number of error-handling proposals suggested different variations on throw-catch, while many others were simply what is called syntactic sugar for if err!=nil return err. Many of these proposals missed the point that the existing error reporting and handling conventions work nicely in a concurrent environment, such as the ability to pass errors via a channel: you can handle errors generated by one goroutine in another goroutine.
An important point I like to emphasize when working with Go programs is that most of the time, they can be analyzed by solely relying...
