Yes, I have heard a lot of discussion about whether the Go style of handling exceptions is “the right way” or not. I would say that it goes in the right direction—it handles exceptions in the same way that Scala handles nulls, which is effectively by replacing them with Options (I hear these were taken from Maybes in Haskell, but not sure), which are either None or Some(value), good for grabbing elements from maps for example. This means that you need to handle them immediately, every time you have an option. Of course, there is the easy way of passing the buck by returning another Option. I don’t have any proof, but I feel like being explicitly forced to handle it instead of being able to just ignore it entirely, is a step forward. In Java, the way with dealing with things that could be null was to annotate them with nullable, or non-null, etc. In C, if I recall correctly, which Go is competing directly with, the best practice for errors was to just store them in errno. I think that putting them directly in the return value is good, if forcing engineers to deal with errors immediately is good, as I think it is.

I am not certain that the Go way of handling exceptions is the be-all and end-all of exception handling, but being more clear is certainly better. Or at least it feels that way.