In our project we have a domain types package with errors that permeate these types of boundaries. It's "okay" in the ways everything in Go is "okay". I've yet to see anything I really like in this space.
Developers as a rule also seem to act strange if you suggest that they made an error. Perhaps the word "error" is triggering in some deep-seated emotional way? I wonder if, in software, we called errors "pineapples" instead if it would avoid triggering such emotions, allowing one to reason about errors in the same rational way they do all other values?
I probably could have made this a bit more clear, but I feel it was a slight tangent to the main point of the post: In any serious app, I wouldn't actually set an HTTP status directly in the db layer. Rather, I would do what others in this thread have suggested: I'd have a set of domain error types/codes, and my DB layer would set _that_.
That domain error value would then implement the `HTTPStatus()` method to return the appropriate status code.
This allows you to have multiple "not found" error codes (as an example) for internal use, which all resolve to an HTTP status of 404.