C++ exception safety
- 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
Assessment
This issue has not been assessed yet.