On the client side, the result of a call is represented by a Task<TResponse> (at least in the unary call case which is the most common). If you think exception dispatching is expensive (possible, but you'd need to benchmark carefully to make sure this is indeed the case, otherwise it's just guesswork), you actually don't have to call "await call.ResponseAsync" and let the exception be thrown. Instead, you could try just detect if the task has finished (failed or successful) and then inspect "call.GetStatus()" to extract the potential error? If there is no error, accessing the Task result is going to be immediate (and cheap).
Another solution is what Christopher has described. On Saturday, October 10, 2020 at 3:02:04 PM UTC+2 [email protected] wrote: > I recently learned rpcException is recommended approach to handle failures: > > 1. server side can > 1.1. throw rpcException with status and meta data filled in trailers > or, > 1.2 set status and trailers to ServerCallContext; > > 2. client will need to catch rpcException to act upon failure situations, > no matter server raised failure via 1.1 or 1.2, because client side library > will create rpcException using status and trailers received, and throw. > > [Q] for heavy and perf critical APP, exception dispatching is also a perf > concern, is it possible to avoid throwing rpcException? (especially on > client side). With that, the Application layer code can look into the > status code to act as appropriately? > > thanks > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5e7cd7b2-17f9-473b-b7a1-6ca284fd41b3n%40googlegroups.com.
