Error Detail wrappers
This project provides wrappers around
as well as an error type wrapping gRPC status codes.
An error created or wrapped by this package can be unwrapped and transcribed to
a Status message type with all the added details intact.
Until inspiration strikes again, all the errors contained herein are derivative
Consider unwrapping these errors to enrich logs as well, they’re genuinely
useful constructs for everyday purposes.
We never utilized the
WithDetails functionality of gRPC Status messages, or
*status.Status at all, preferring instead to use regular old errors with
a translation layer in middleware.
There’s so much more knowledge you can express in a Status response coming
right from your API layer though, and I wished for some way to make the Status
message and arbitrary details more palatable to a team already familiar with
At the same time, I wanted a unified error response body from all our JSON
API’s, even the ones not transcoded from gRPC.
If only I could just, wrap a Status message with Details like an error.
And if only I could write my wrapped error right through a middleware layer to
turn it into JSON.
Until recently, I was struggling to understand when I should use an interface
type in Go.
what, and mostly
why, but the intuition wasn’t all here.
While working on localizations for a project, it started to click a bit.
Inspiration hit when I wanted to combine localizability with errors, and maybe
also a request ID, and wouldn’t ya know it suddenly I couldn’t sleep with all
the notes I had to write to myself in the “Probably Ideas” category, because
errdetails is a thing that exists.
So to reinforce and practice the point till intuition, and also to get it out
of the head so I can sleep again, I popped this old idea off the ol’
list and got to writing something I’ll probably never maintain or use, but
maybe I will and it’ll be nice.