Exploring Error Handling Patterns in Go
I wish more developers could do &quot;investigation&quot; like this for a new languages they learn.<p>For me, the main difference between Go&#x27;s way of handling language and the rest of mainstream languages is that it makes error handling <i></i>unmagical<i></i>.<p>It literally says – errors are just like any other return values. Let&#x27;s say, if you have function `sqrt` and return a value, and then call this function – you probably is interested in this return value and should handle it somehow (or mute with `_`). Now, the same applies for errors - if function returns the error, you likely to think how to handle it – do something in place or propagate up the stack.<p>There is also a cultural moment to this. As we mostly learn by examples, and most Go code has proper error checks (not equal to &quot;proper error handling&quot; but nevertheless), it makes newcomers to do the same as well, even while disagreeing with Go&#x27;s way. I&#x27;ve heard from many devs that Go was the reason that made them appreciate proper error handling.<p>And honestly, I feel this too, and I think the reason is that in Go it&#x27;s too easy to &quot;handle errors properly&quot;. I never had this feeling with languages with exceptions, where I had to read whole books (!) just to learn how to properly use them and be confident in the way how I handle errors. (this is just an example, not the spark to start return values vs exceptions battle, just in case)