I thought your comment was about how we lost information in the exception raised, we already have a bug to refactor code to a non-exception case (#35).

If we create a subclass of std::exception (is that the right pattern?), would it still be thrown?

That is the right pattern, and yes, it would be thrown/raised.

And if so, would it work for folks who set -fno-exceptions?

It would not work, but nor is that interesting. This is for the folks with exceptions. We need to do something different for the internal classes that will not use exceptions.

Would we want to return a StatusOr<T>

StatusOr<T> is not a thing btw. There is nothing like it in standard C++, nor in abseil. There is a proposed thing like it (std::expected<T,E>) for C++20...

instead from a function, which the caller can inspect, and throw an exception if needed?

The design doc and #35 expect that we will refactor classes without exceptions, we would return a value and then raise in the thin wrappers for external users. We should discuss whether it makes sense to implement versions of the admin interfaces without exceptions though.

Create std::exception that wraps a grpc::Status #119

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions