> How? With “raise from”, Python shows you not only the stack trace of the error, but also the stack trace of the original exception, IIRC.
Because you can't catch the original exception, you're stuck with weird module.Error which is too generic to do something about it. You would have to catch the module.Error and then look at e.__cause__ to actually handle the exception. So you end up with the exact same problem Parthenon is talking about, but with extra steps.
And pray no other dependencies are following your practice, because you would then have to go into e.__cause__.__cause__ and so on.
What exactly is the benefit that module.Error provides to your users compared to letting the original exception propagate?
> Because you can't catch the original exception, you're stuck with weird module.Error which is too generic to do something about it.
To be clear, I most often do not raise plain module.Error; I generally raise semantically informative errors like module.FooError or module.EntityNotFoundError, all of which inherit from module.Error.
> What exactly is the benefit that module.Error provides to your users compared to letting the original exception propagate?
I thought that I (and Parthenon) made that clear; it’s to protect the users of my module from having to know about my implementation details. If I switch from a socket-based approach to an HTTP-based system internally, I don’t want my users to have to know that and switch from catching socket.error to requests.Error or other_http_module.Error. Implementation details should not be a part of the API.
I’ve come to this view from, when investigating a runtime error, too often having to dig into the source code of some third-party module to investigate what kind of exception class I’ve gotten in my traceback, only to discover that it’s not an exception from that module, it’s an exception class from yet another module that the third-party module is itself using, and which I had no way of knowing could be raised. I then have to not only catch that exception in my code (which ties my code to implementation details of the third-party module, i.e. making my code brittle), but I also have to import the module containing the exception (in order to name the exception class in order to catch it), which increases my code’s direct dependencies.
Because you can't catch the original exception, you're stuck with weird module.Error which is too generic to do something about it. You would have to catch the module.Error and then look at e.__cause__ to actually handle the exception. So you end up with the exact same problem Parthenon is talking about, but with extra steps.
And pray no other dependencies are following your practice, because you would then have to go into e.__cause__.__cause__ and so on.
What exactly is the benefit that module.Error provides to your users compared to letting the original exception propagate?