gRFC L17: C++ synchronous server should catch exceptions from method handlers

[Vijay Pai]

Hi all,

I have posted a new proposal at https://github.com/grpc/proposal/pull/51 to help improve server robustness in the presence of method handlers that trigger C++ exceptions. Please feel free to discuss in this thread.

Regards,

vjpai

[Vijay Pai]

I've gotten a question about whether this implies that gRPC will throw exceptions. The idea that we will catch exceptions is separate from the idea of throwing exceptions, and we can happily do the former without doing the latter. The googletest library is a great example here; it catches exceptions (and marks tests failed that have exceptions) but does not itself throw exceptions. It also builds just fine in platforms that don't allow exceptions. This gRFC says that gRPC should behave the same way.

[Christopher Warrington - MSFT]

From the proposal:

> If the method handler throws a std::exception, the sync server will treat
> it as though it returned an UNKNOWN Status marked with the what result of
> the exception as its error message.

Is the proposed behavior in line with the security model used for gRPC's
default choices? The proposed behavior implies that the server is
communicating with somewhat trusted clients. A more paranoid choice would be
to respond with a generic "An unexpected error has occurred" message to avoid
leaking potentially sensitive exception details.

--
Christopher Warrington
Microsoft Corp.

[Vijay Pai]

Thanks for the excellent feedback. That's a reasonable point since the exception may not have been issued directly by the method handler but rather by something many levels underneath (as pointed out in the justification for the proposal).

--
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 grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
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/7d3e6241-8dd0-4cb2-81f8-54bebc86badb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vijay Pai]

I updated https://github.com/grpc/proposal/pull/51 to account for the feedback given in this thread.

On Monday, January 8, 2018 at 4:53:34 PM UTC-8, Vijay Pai wrote:

Thanks for the excellent feedback. That's a reasonable point since the exception may not have been issued directly by the method handler but rather by something many levels underneath (as pointed out in the justification for the proposal).

On Mon, Jan 8, 2018 at 4:50 PM 'Christopher Warrington - MSFT' via grpc.io <grp...@googlegroups.com> wrote:

From the proposal:

> If the method handler throws a std::exception, the sync server will treat
> it as though it returned an UNKNOWN Status marked with the what result of
> the exception as its error message.

Is the proposed behavior in line with the security model used for gRPC's
default choices? The proposed behavior implies that the server is
communicating with somewhat trusted clients. A more paranoid choice would be
to respond with a generic "An unexpected error has occurred" message to avoid
leaking potentially sensitive exception details.

--
Christopher Warrington
Microsoft Corp.

--
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 grpc-io+unsubscribe@googlegroups.com.