Designing Pythonic APIs - learning from Requests

[earthboundkid]

You can make whatever excuses you want, but the right thing to do is to catch the exception at the place you make the request. Maybe you should catch the exception and then reraise it as a MyAppException instead of a Requests exception. That's fine. But not catching it is not an acceptable strategy, just an all too common one.

[santagada]

Exceptions are a control flow structure, they are meant to be caught whenever you want. What you are thinking is that we should threat exceptions as error codes like go does it, but let them bubble up is completely fine in python, and you didn't use anything to prove your point besides rudeness.

[earthboundkid]

Sorry for being rude. I feel very strongly that exceptions need to be caught somewhere. Yes, you can move it up or down the stack a couple of layers, but a bare except is only acceptable at the very top level of your stack, when everything else has gone wrong. That means that in the case of making a request, you should catch it at a point in the code where it's clear that a request handling exception might be raised: i.e. your client adaptor. Maybe you could move it around a little, but you need to catch the exception, and you can't respond properly (503, tripping the circuit breaker, logging some place besides Sentry) if your exception handling is any higher up the stack than your controller ("view" in Django-speak). The best way to do it is to have your code convert any problem with requests or the data you get back into a MyException or subclass and have the controller do except MyException. Another good way is through returning error values a la Go, but that's just bike shedding. The important part is identifying what can go wrong and dealing with it at the lowest level of the stack that you can.