Arnoldas Grigutis's blog

The results of Go Developer Survey 2022 Q2 came out and showed that error handling and working with stack traces in Go pose the biggest challenge to respondents: "Error handling remains a challenge. Following the release of generics, respondents' top challenge when working with Go shifted to error handling." The answer distribution is as below (click): In this blog post I would like to focus on error handling and try to explain in detail how, in my view, error handling in Go is or should be done. Ready? Let's begin. Error handling in Go explained A function or a method in Go returns a non-nil error if and only if it encounters an error during execution. The caller checks for the returned error value - if it is not nil, it either handles it or returns an error of its own. I hope this blog post makes Go error handling better understood and appreciated.  

Several months ago I built a web service in go which, inspired by the blog post "Packages as layers, not groups" , I made strictly layered. Not to make a rule out of it and not saying that this is what packages are, I think using packages as layers for different building blocks of an application (RPC, business logic, storage, cache, auth, etc) helps a lot in structuring an application. There was another blog post that talked about using separate structs for the same model (or data transfer object) in each microservice or layer, as opposed to re-using the same struct from a single library and so introducing a dependency everywhere. I cannot find it any more but I loved the idea and I used it in my app as well. I wanted to put these two ideas out there and so I changed all the code from the original app and made it a dumb key-value storage REST API. The project is on GitHub: https://github.com/varfrog/layers . Comments are welcome!