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

Add client exceptions #55

Merged
merged 1 commit into from
May 31, 2024
Merged

Add client exceptions #55

merged 1 commit into from
May 31, 2024

Conversation

llucax
Copy link
Contributor

@llucax llucax commented May 31, 2024

Add a ApiClientError exception that is the base class for all client exceptions. This exception is raised when there is an error in the client. We also wrap all gRPC response errors in a GrpcError exception that is a subclass of ApiClientError, and add one subclass for each possible gRPC status code.

This makes error handling more pythonic, as one can now just catch the exception type one is interested in, without having to do a second-level matching using the status.

It also helps avoiding to expose the grpclib classes to the user.

@llucax llucax requested a review from a team as a code owner May 31, 2024 07:13
@llucax llucax requested a review from shsms May 31, 2024 07:13
@github-actions github-actions bot added part:docs Affects the documentation part:tests Affects the unit, integration and performance (benchmarks) tests part:code Affects the code in general labels May 31, 2024
@llucax llucax self-assigned this May 31, 2024
@llucax
Copy link
Contributor Author

llucax commented May 31, 2024

This is a port of:

With the following changes:

  • Renamed ClientError to ApiClientError to make it less ambiguous in contexts where there might be other types of clients (like a customer).
  • Made it compatible with grpcio too, at the expense of type checks being deferred to runtime. This should be temporary though, until we can battle-test betterproto and decide if we do the switch or stay with grpcio. I tried a type-safe approach using generics but it was too intrusive, as we would have to explicitly mention the underlying grpc error type when using every exception, like OperationTimedOut[GrpclibError].
  • Added 2 properties to GrpcError: grpclib_error and gprcio_error to make it easier to access the underlying error for a particular library
  • Added a list of subclasses in the docs, so it is easier to have a quick look at every possible gRPC error one could encounter.

Add a `ApiClientError` exception that is the base class for all client
exceptions. This exception is raised when there is an error in the
client. We also wrap all gRPC response errors in a `GrpcError` exception
that is a subclass of `ApiClientError`, and add one subclass for each
possible gRPC status code.

This makes error handling more pythonic, as one can now just catch the
exception type one is interested in, without having to do a second-level
matching using the status.

It also helps avoiding to expose the grpclib classes to the user.

Signed-off-by: Leandro Lucarella <[email protected]>
@llucax llucax added this to the v0.5.0 milestone May 31, 2024
@llucax llucax added this pull request to the merge queue May 31, 2024
Merged via the queue into frequenz-floss:v0.x.x with commit 7cca5b2 May 31, 2024
14 checks passed
@llucax llucax deleted the exceptions branch May 31, 2024 10:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
part:code Affects the code in general part:docs Affects the documentation part:tests Affects the unit, integration and performance (benchmarks) tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants