TOTALLY agree with you. I only use `Status` to check whether the service response is good.
On Tuesday, March 10, 2015 at 8:02:41 PM UTC+8, Andrey Myznikov wrote: > > Hello Folks, > > I found the use of grpc++ in real applications to be much problematic > due to wide usage of GPR_ASSERT() macro in grpc++ for error checking. > The macro from gprc/support/log.h is intended only for internal invariants > checking, and calls abort() if assertion fails. > > But in grpc++ it is used for all error checks, including recoverable > run-time errors. > > For example, the fragment of code from BlockingUnaryCall(): > GPR_ASSERT((cq.Pluck(&buf) && buf.got_message) || !status.IsOk()); > return status; > > For what to "return status" from here if it always will be OK ? > > This leads to abort my application on connection loss or on other > recoverable errors. > > The comment to this macro says: If the error can be recovered from, > without the possibility of corruption, or might best be reflected via an > exception in a higher-level language, consider returning error code. > > I expect to get some error code in my application, or some c++ exception > as the last resort. > But do not abort() my application. > > What you thinks should be the best way to get rid these abort's on > recoverable errors? > > Can I hope that the problem will solved in the immediate future releases > of grpc++ ? > > > 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4f39be20-77a3-48f1-a4cb-c55031b6a952%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
