Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apierror: simplify extraction of custom errors #212

Closed
shollyman opened this issue Jul 21, 2022 · 0 comments · Fixed by #213
Closed

apierror: simplify extraction of custom errors #212

shollyman opened this issue Jul 21, 2022 · 0 comments · Fixed by #213
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@shollyman
Copy link
Contributor

shollyman commented Jul 21, 2022

Within apierror, the ErrDetails type holds decoded values from an rpc status:
https://pkg.go.dev/github.com/googleapis/gax-go/v2/apierror#ErrDetails

Custom messages such as service-specific custom error types end up in the Unknown slice of ErrDetails, which is a slice of empty interface types. It would be beneficial to provide a utility mechanism for extracting a message of a given type from the ErrDetails.

By way of example, the bigquerystorage service has a StorageError type:
https://pkg.go.dev/google.golang.org/genproto/googleapis/cloud/bigquery/storage/v1#StorageError

Being able to more easily extract this from APIError would be lovely. Perhaps something like this might make sense?

if msg := apiErr.Details().ExtractDetail(&storagepb.StorageError{}); msg != nil {
  if se, ok := msg.(*storagepb.StorageError); ok {
    // do something with the storage error
  }
}

Also happy to make the change if this seems reasonable.

cc @noahdietz @quartzmo

@shollyman shollyman added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. priority: p3 Desirable enhancement or fix. May not be included in next release. labels Jul 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant