uplink: How should exceptions from underlying client libraries be handled?

Thank you, I really appreciate your effort to solve this issue. I like that it is responsibility of an adapter to correctly expose required exceptions, also I like that http client now carries all essential bits of interface to use.

@daa - I took another shot at this: #117

Dynamic superclassing is clever but I’m afraid it’s too hacky and may rely on implementation details, and personally I prefer more simple and straightforward code. Also Python data model documentation (https://docs.python.org/3/library/stdtypes.html#special-attributes) tells us that __bases__ is supposed to be read-only attribute even if it can be changed actually but not for built-in exceptions. I’ll repeat this is clever trick but it patches unrelated code someone other is responsible for, which may be seen as a problem from maintenance point of view, and articles and stackoverflow answers describing similar technique warn that this should not be normally used.

At all I think problems and hacks arise from two contradictory wishes:

• first, wish to know raised exceptions upfront
• and second, wish to use original exceptions from underlying client which may be not known until consumer configuration Upfront visibility of exceptions is useful when we consider for example decorators providing retry functionality, and availability of original exceptions is useful when fine control over process is desired.

At the end I have another idea, may be not so bright as dynamically setting superclass, and involving more code - you may define hierarchy of client exceptions and then dynamically construct proxy classes for real exceptions as inherited from real exception class and corresponding uplink client exception class and then reraise them instead of original. It’s not very elegant but sufficiently self-contained.

Also you may look at django if you haven’t already - they had similar issue and similar thoughts - https://code.djangoproject.com/ticket/15901 - and decided to wrap exceptions to their own, but they had simpler case - all needed exceptions were listed in pep and libraries conformed to it.

Again, thank you for your work, this issue happened to be rather difficult and non-obvious and involve different tradeoffs.

Thank you, nice work. It’s a pity that approach with virtual subclasses didn’t work, it was a nice idea. Exceptions proxying should work for most cases. But I can see one drawback following from that proxies are tuples named like exceptions but not exceptions themselves: one cannot catch several client exceptions in usual manner. For example following code will not work at python3:

try:
      x = cons.method()
except (client_exceptions.ConnectionError, client_exceptions.InvalidUrl):
    ...

It will result in TypeError: catching classes that do not inherit from BaseException is not allowed, one should write except client_exceptions.ConnectionError + client_exceptions.InvalidUrl: instead. Interestingly that code will work for python2, and isinstance(e, (client_exceptions.ConnectionError, client_exceptions.InvalidUrl)) at both Pythons will not complain and work as supposed. However, I don’t know how to do better than you’ve done. Also it’s questionable whether such exception handling as in example is reasonable, sane and required at all.

Started working on this in #70.

FYI: @daa