It would make handling of timeouts much cleaner if FutureTimeoutError had methods like code() and details() etc, the same as, say, _InactiveRpcError does.
Is this a design decision? Would the grpc community be open to a pull request that changes the implementation of FutureTimeoutError in this way?
grpc.FutureTimeoutError is the exception raised when a grpc.Future.result or grpc.Future.exception exceeds deadline but haven't got any result. For example, the RPC takes 10 seconds to finish, but we got result(timeout=2). Then the grpc.FutureTimeoutError will be raised to indicate time's up after 2 seconds. And the RPC isn't near finishing at that time, so we can't access code() and details().
This is not a RPC issue on either the client or the server, which means grpc.RpcError may not be a good fit for grpc.FutureTimeoutError.
why is grpc.FutureTimeoutError not an instance of grpc.RpcError and grpc.Call?