> 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).
Re:Multiversion Python Thoughts
by snatchpiesinger on Tuesday October 01, 2024 @10:17AM
(#41708787)
It'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.
Sure, 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.
It should be safe to use multiple versions of the same library, as long as they are used as private dependencies of unrelated dependencies. It would require some tooling support to do it safely:
1. Being able to declare dependencies are "private" or "public".
2. Tooling to check that you don't use private dependencies in your interfaces. This requires type annotations to gain some confidence, but even then, exceptions are a problem that is hard to check for (in Python that is).
In compiled languages there are additional compilications, like exported symbols. It is solveable in some controlled circumstances, but it's best to just not have this problem.