grpc / grpc/grpc

C++ exception safety

Open
#13,706 8 comments 0 reactions 1 assignee Claimed by @markdroth View on GitHub
area/api disposition/never stale kind/internal cleanup lang/c++ priority/P3
Dominant language
C++
Stars
45.3k
Forks
11.4k
Avg merge
2d 12h
Merged PRs (30d)
47

Description

Tracking issue to determine whether or not the gRPC core/C++ layer is safe wrt exceptions thrown in application code. Although it is a [Google standard not to throw exceptions](https://google.github.io/styleguide/cppguide.html#Exceptions), we do need to make sure that gRPC doesn't interfere with application writers use of exceptions. We also need to make sure that we don't cause exceptions indirectly

Implications of the above:
1. Don't call libraries that can throw exceptions (e.g., `std::thread`)
- special case for `new` where an exception is essentially unrecoverable anyway
- UPDATE 3/4/2018: Resolved in #14459
1. Check places where something must be called before calling a destructor and attempt to remove those
- e.g., a ServerCompletionQueue must be explicitly drained now before its destructor is called
1. If we call an application-level callback that is not in our control, `catch` any exceptions that it might throw so that we can recover safely
- e.g., if a service method handlers throws an exception, gRPC C++ should just return with a bad status rather than failing
- UPDATE 3/4/2018: Resolved in #13815

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.