3 ms·
> you don't throw it or catch it Herein lies the issue: in this context exceptions can be thought of as the same as returns. So you actually need to catch/hand
by orf 2y ago
> you don't throw it or catch it
Herein lies the issue: in this context exceptions can be thought of as the same as returns. So you actually need to catch/handle all possible exceptions in order to not leak private types.
Also what does “except requests.HttpError” do in an outer context? It checks the class of an exception - so either it doesn’t catch some other modules version of requests.HttpError (confusion, invariants broken) or it does (confusion, invariants broken).
- snatchpiesinger 2y agoIt's fine as long as you catch all exceptions, and only produce ones that you document. Your users aren't supposed to know that you used `requests` at all.
- orf 2y agoSure, but who does this? And the typical pattern is to wrap exceptions, giving you access to the inner exception if you need more context. The requests HTTP exception contains the request and response object. Wrapping that would be a huge pain and a lot of code.