To be clear, I'm not saying you can't handle database problems. If there are situations where a recovery path is possible and worth the effort then by all means do that (that becomes an expected error now*). However, in a lot of cases it's not possible or simply not worth it since a retry mechanism is almost always better situated outside the request, job, etc entirely. So, fail fast (panic) within the unit of work itself. I explain more about his in my response to Danilkin.

To your point about handling errors explicitly to invoke a rollback. Well, you still need a panic recover anyway since you can never guarantee that the application will not fail outside of your control during the TX. A divide by zero, or a panic from the Go stdlib, for example.

I believe the panic gives great context because you always have a full stack trace. Unlike errors, which if you forget to wrap them with pkg/errors or manually prefix them at every single point up the chain the visibility is much worse than a panic.

* I'm not that happy with the terminology I have used and tend to use "unexpected" and "unresolvable" interchangeably. Unexpected doesn't mean something that can't happen, but rather a type of error where we have no reasonable recourse for.

Written by

I’m a data nerd and TDD enthusiast originally from Sydney. Currently working for Uber in New York. My thoughts here are my own. 🤓

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store