Error Flows in Go · Preslav Rachev
The following post is a spiritual successor to an essay on error handling in Go I wrote in 2023. It’d recommend anyone who hasn’t read it to check that one out first.
Have you ever thought of what happens with errors in your Go apps? From the point of view of your Go application, there are three distinction points where something happens with an error:
From experience, unless you are building a library, you will likely not spend a lot of time introducing new errors to your application. Like every other Go application out there, yours will either use the standard library directly or rely on a library that uses it. Hence, the chances of dealing with an existing error when using a file or a database connection are far higher than when your app needs to invent a new one out of thin air.
This is plain useless. I stressed the importance of wrapping all errors with useful context, and I still firmly stand by that. What I believe people are getting wrong is the messaging part of the context. Too often, I see messages trying to tell me what went wrong. Instead, they should have told me what they tried to do just before things got messed up.
