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

generated service client and methods have different error type #36

Open
dpennell opened this issue Apr 3, 2020 · 2 comments
Open

generated service client and methods have different error type #36

dpennell opened this issue Apr 3, 2020 · 2 comments

Comments

@dpennell
Copy link

dpennell commented Apr 3, 2020

Using example client project:

The generated service client has a signature of Layer[Throwable, GreeterClient]
The generated methods have signatures of ZIO[GreeterClient, io.grpc.Status, examples.greeter.Response]

This results in widening the error type to Any

I've worked around this by using mapError to map io.grpc.Status into a Throwable

@thesamet
Copy link
Contributor

thesamet commented Apr 3, 2020

Thanks for opening this issue.

What would be the expected change to resolve this? Possibly one of:

  1. Fix the client example to demonstrate the types in play and how to use mapError to get back to throwables.
  2. Change the generated code to use StatusException instead of Status?

I found during development that indicating failure seemed cleaner using Status rather than an exception, but that was a personal preference. Agree it looks like it can get in the way when combined with other code that can fail with an arbitraryThrowable.
FWIW, using mapError(_.asException) (or mapError(_.asRuntimeException)) would be the simplest way right now to map it into a subclass of Throwable.

@dpennell
Copy link
Author

dpennell commented Apr 4, 2020

The layer uses Throwable, generated service calls use Status and your application/domain code may use a third type.
I think that usage with domain code implies a need for either Throwable or a domain specific type, so the layer and generated service calls should align "out of the box" and not widen to Any. My first inclination would be to pick Status, but I assume the layer uses Throwable for a reason.

Thanks for the tip on asException and asRuntimeException. At least I don't have to define my own subclass of Throwable.

@scalapb scalapb deleted a comment from dpennell May 10, 2020
@scalapb scalapb deleted a comment from dpennell May 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants