If we wanted to go big, the other option is that the package could define a set of custom errors and make them available to the user -- then the user could potentially use errors.Is()
if errors.Is(err, ErrNeedReAuthorization) {
... application could inform the user and ask for input before initiating the process again
}
I wrote up a quick example of what a custom error system might do, including a custom error struct, custom error messages, and two examples of errors.Is(), and how the handler might be able to leverage that to pass back more information to the caller: https://go.dev/play/p/tAJIlc1zFcL
https://go.dev/blog/go1.13-errors is the standard intro to error wrapping. Ultimately industry standard is more or less to wrap when you need to and always avoid wrapping implementation details.
what would you like to see (describe affect rather than mechanism, if possible)?
as per @jazzboME