GaxError is no longer raised in 0.13.0 when expected

[dhermes]

For example, when getting a non-existent topic we expect a GaxError but see a grpc._Rendezvous instead.

Related: googleapis/google-cloud-python#2336

[geigerj]

I can reproduce this:

$ virtualenv venv
$ . venv/bin/activate
(venv) $ pip install gapic-google-pubsub-v1
(venv) $ python
Python 2.7.12 (default, Aug 24 2016, 08:19:55) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from google.cloud.gapic.pubsub.v1 import publisher_api as p_api
>>> api = p_api.PublisherApi()
>>> topic = api.topic_path('MY-PROJECT', 'my-topic')
>>> api.get_topic(topic)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/google/cloud/gapic/pubsub/v1/publisher_api.py", line 291, in get_topic
    return self._get_topic(request, options)
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/google/gax/api_callable.py", line 480, in inner
    return api_caller(api_call, this_settings, request)
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/google/gax/api_callable.py", line 468, in base_caller
    return api_call(*args)
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/google/gax/api_callable.py", line 430, in inner
    return a_func(*args, **kwargs)
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/google/gax/api_callable.py", line 64, in inner
    return a_func(*updated_args, **kwargs)
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/grpc/_channel.py", line 481, in __call__
    return _end_unary_response_blocking(state, False, deadline)
  File "/usr/local/google/home/jgeiger/gax-test/venv/lib/python2.7/site-packages/grpc/_channel.py", line 432, in _end_unary_response_blocking
    raise _Rendezvous(state, None, None, deadline)
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with (StatusCode.NOT_FOUND, Resource not found (resource=my-topic).)>

We should talk with the gRPC folks (@nathanielmanistaatgoogle et al). I'm somewhat uncomfortable with catching _Rendezvous because it's underscore-prefixed, and so not supposed to be public. I am surprised that gRPC is raising an exception with a non-public type.

[dhermes]

@geigerj Ditto. We have googleapis/google-cloud-python#2156 for that discussion as well.

[nathanielmanistaatgoogle]

@geigerj: gRPC is raising an exception with a non-public class, but the public types of the instance that is raised are grpc.RpcError and grpc.Call. Our intention is that application code be written something like

try:
    my_response = my_stub.MyMethod(my_request)
except grpc.RpcError as rpc_error:
    my_status_code = rpc_error.code()
    my_status_details = rpc_error.details()
    <statements taking action in response to the terminated RPC>

.

[dhermes]

@nathanielmanistaatgoogle But what you're actually forcing users to do is

try:
    foo()
except grpc.RpcError as grpc_err:
    if isinstance(grpc_err, grpc.Call):
        code = grpc_err.code()
    else:
        raise

(Already mentioned this in googleapis/google-cloud-python#2156)

[nathanielmanistaatgoogle]

@dhermes: I don't understand the need for the instance check?

[geigerj]

@nathanielmanistaatgoogle What is the relationship between RpcError and AbortionError? Is AbortionError ever still raised?

[nathanielmanistaatgoogle]

@geigerj: AbortionError is only ever raised from the Beta API; it is entirely replaced by grpc.RpcError in the GA API.

[geigerj]

@nathanielmanistaatgoogle @dhermes Correct me if I misunderstood, but I think @dhermes's concern comes from the fact that grpc.RpcError does not define any attributes; the code() method is defined on gRPC.Call. So to be safe, I would expect either to do the isinstance check or to wrap the call in a try/except block. There doesn't seem to be reason to expect from having a grpc.RpcError alone that it would have a code() method.

[dhermes]

/cc @tseaver

@nathanielmanistaatgoogle Maybe we should have a more centralized place for this discussion?

[nathanielmanistaatgoogle]

@dhermes: absolutely have that discussion, but if you'll indulge me I'd rather observe it than lead it. I intended for the API to be clear that the exception raised will implement both types and can (without having to check first) be used according to both types so I'd like to see where the ambiguity is creeping in.