These days I’m working with some crazy APIs and I stumble into this warning from pylint:
I know what the problem is. They want you to make sure you catch specific exceptions – it’s bad form to catch all, you should catch only those you can handle. But here’s the problem.
Your API defines an exception kind, from which all exceptions should be derived. But when I create an object you throw me some random system exception and I can’t tell which one. And I can’t test all exceptional cases, because I literally cannot. I don’t know – I don’t want to read your implementation, nor the implementation of the framework you’re using. So what am I to do? That’s right, catch all exceptions. Because I don’t really need know what the heck happened, only that things didn’t happen. Exception handling became error handling, only with a different pattern. But I don’t care about handling errors, I’ll just shut down the connection to your service and inform the user about it.
That’s what happened – sometime in the 2000s exceptions became synonymous with errors. You don’t really say there was an error, you prefer to return void and throw an exception. Then we can never know which exception you’re throwing, because it’s Python, so who the heck cares about types? Types are just labels, man1)imagine a pothead saying that.
Not only I don’t know which exceptions you might throw, but I really don’t care nor want to care about these exceptions. I don’t want to know what intricate exceptions you throw, because I think quite binary: the operation succeeded or it did not. And if I expect exceptions to be really exceptional, I’ll just let them wreck my whole runtime, and stop the program.
But in this case, your insignificant secondary support library will not be allowed to do that to my program. So I’ll catch all exceptions.
NOTES [ + ]
|1.||↑||imagine a pothead saying that|