-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Ability to propagate cause
when using StatusProto.toStatusException
#10900
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
Comments
cause
when using StatusProto.toStatusExceptioncause
when using StatusProto.toStatusException
cause
when using StatusProto.toStatusException
cause
when using StatusProto.toStatusException
Cause isn't sent over the wire, so the status isn't being used for an RPC? StatusProto's API was designed to make sure io.grpc.Status and com.google.rpc.Status agree. It'd be very bad for one to say OK and the other to be PERMISSION_DENIED, for example. But it sounds like you are using com.google.rpc.Status within your process for error information. Can you explain more about how your app code is organized to use this? |
Thanks for the reply! The way our application is designed is that exceptions in our gRPC services are expected to ultimately return We recently incorporated com.google.rpc.Status into our responses in order to provide a richer payload of response data (invalid fields with BadRequest, etc.) but prior to that we were just using
When we logged this we would get the stack trace from the cause, which can be useful for debugging. For now we are working around it by building the |
I see. Local logging. That's quite fair. Worst-case adding a overload that also receives a Throwable could work. I don't think we'd have a Metadata-less overload, but maybe Metadata would be permitted to be null instead of required. But we have a few overloads, so it'd probably be good to look around to see if there's something more natural (I'm not seeing anything immediately, but I've only spent 15 seconds looking at it). |
@ejona86 What is your thinking - is this an enhancement we should take up? |
I do think we should do something here. There's just the question of the API. |
I think the easiest/best think right now is just to add another overload (like I said in #10900 (comment)). I don't think there's going to be any cleaner API unless we introduce a builder. Feel free to send a PR. |
Is your feature request related to a problem?
When converting a
com.google.rpc.Status
to anio.grpc.StatusException
I can't find a way to propagate acause
with the resultingStatusException
.Currently
StatusProto.toStatusException
is defined as:However, using this method there doesn't seem to be any way of providing a
cause
.Describe the solution you'd like
My ideal would be to make
StatusProto.toStatus
public, which would allow creating the status and callingasException
something callers could do themselves. This would also be helpful in scenarios where callers require aStatus
instead of aStatusException
.Describe alternatives you've considered
It feels a little clunky, but I'd be open to having an extra parameter on
toStatusException
for thecause
, or another solution depending on the preferences ofgrpc-java
maintainers.I've also tried calling
initCause
on the resulting StatusException, but that isn't possible because the cause is set tonull
in theasException
code, soinitCause
throws anIllegalArgumentException
.Additional context
The text was updated successfully, but these errors were encountered: