Returning an error from GRPC handler about grpc HOT 18 CLOSED

So should I go ahead and start working on a PR for that?

from grpc.

@xenolf Good question. It's already on the TODO :) I haven't decided how to return the error, raising an error is one way to do that.

from grpc.

@tony612 what is your take on that? I'm in need of this functionality and would offer to implement it but wanted to start a discussion first.

from grpc.

I think we can try raising errors first. The code in grpc-elixir should handle the errors and return errors to the client side. Then errors will be raised on client side. How do you think about it?

from grpc.

Yeah I was thinking to define error types for the errors specified in https://github.com/grpc/grpc/blob/master/doc/statuscodes.md . The server code could then just raise an error like GrpcUnauthorizedError which gets rescued by library code. The response code gets set as defined inside of the error being raised.

The client side would simply check for status code != 200 and raise the appropriate error based on the code.

from grpc.

But I don't think application code can specify the status code. Most of the status codes are certain due to the reasons like DEADLINE_EXCEEDED(4) or UNIMPLEMENTED(12). If there're errors raised in application code, the status code will always be UNKNOWN(2). So for your situation, I think we just need to rescue all errors in handlers, then return UNKNOWN(2) with the error message. Right?

For other errors, it's a different problem. We should do that in a separated PR.

from grpc.

gRPC status codes are only used to express the basic statuses of gRPC requests. If you need the application level status code, you have to define them by yourself in your service definition and return the responses with status code, messages or whatever else.

from grpc.

btw, as the Wire format says, I think the server side should always return 200. The status code should be in Status HEADER. gRPC is using HTTP/2, but it doesn't use :status.

from grpc.

You are right, I've mistaken the status header for the :status field. But applications can influence the header value in other implementations. Take for example the official GRPC C# implementation, where the handler code may raise an exception with a status code and an optional error string as in the following snippet:

throw new RpcException(new Status(StatusCode.Unauthenticated, "Wrong username or password"));

C++ allows for this to be done through the responder object passed into the handler function. This object defines a FinishWithError function which looks like this:

responder.FinishWithError(Status(grpc::UNAUTHENTICATED, "Not authenticated"), tag);

The status codes for this are defined here for C# and here for C++.

from grpc.

But the status codes are not application level, even for UNAUTHENTICATED, which just means auth of gRPC not your own auth. Please figure out what's the meaning of all gRPC status codes. Though some implementations may support custom grpc status code, others don't. So I think we shouldn't allow this in grpc-elixir.

from grpc.

From what I can see from my search is that all official GRPC implementations do support this application level setting of the grpc-status header and they also define the same status enumerations as the ones I posted above.

from grpc.

I see. But I don't know in what situations, people would like to use gRPC defined status codes(each of them has a specific meaning) as application codes. I think grpc-elixir should not allow this at the moment.

from grpc.

I can't tell you when other people might use it but we are using it as a replacement for HTTP status codes. When I read the descriptions in the links to the status definitions I posted above, I get the impression that they are also meant for application level errors, not just for GRPC internal use. Take for example the defined codes for NOT_FOUND and ALREADY_EXISTS. These codes do not even make sense for a GRPC only error code.

The benefit we see is that when we use these status codes to convey errors, we don't have to implement our own way for sending errors down through meta data or even embed them in our proto definitions. All implementations we use do signal the error to the client code through exceptions or other means which we can handle without having to write the logic for checking meta data ourselves.

from grpc.

That makes sense. So.. there're two situations:

1. Application code raises gRPC defined errors(with gRPC defined status code and custom message). The errors should be returned to the client directly.
2. Application code raises other errors. An error of UNKNOWN(2) should be returned.

How about it?

from grpc.

Sounds fine to me.

from grpc.

@xenolf Sure. Please go ahead 😄

from grpc.

Any progress so far?

from grpc.

@acroca I think this PR has solved this issue #36

from grpc.