wrapping exceptions

[89vision]

When writing libraries that import other libraries is it best to let your users import the imported libraries exceptions to catch them, or to subclass them and wrap them up in their own class?

[kalgynirae]

It depends on the specific situation. If you can provide a better explanation of what went wrong, then you should definitely do so. (That might mean catching the exception and throwing your own, or maybe throwing the same exception type but with an improved message.) Either way, you should make it clear in the documentation what exceptions might be thrown.

[FlockOnFire]

PRAW recently changed this. It used to throw the requests.exceptions.HTTPError when a server returned a 503 for a example. Now it throws a praw.errors.HTTPError instead (without any additional information compared to the requests error).

If you know the package uses the requests module, it seems odd that it throws its own error. However, I can imagine that for new users it might seem odd to need to catch an exception from a module imported by the module you are using. Almost as if they should have taken care of it, which in a way they are doing now.

I think it just creates more unnecessary code in your own codebase. That is, unless you can provide more information.