3 ms·
I've had and seen this philosophical debate a few times. To me, "if anything goes wrong, do the following" is perfectly valid semantics that appears a lot, and
by BurningFrog 2y ago
I've had and seen this philosophical debate a few times.
To me, "if anything goes wrong, do the following" is perfectly valid semantics that appears a lot, and a bare excepts is a fine way to implement that.
I think what confuses these discussions is that a common "rookie mistake" is slapping on a bare except when you really should be specific.
For some people, this is reason enough to blindly enforce a "bare excepts" rule. To me, the costs vastly outweigh the benefits in this case.
At it's core, this might be a personality type issue more than anything else.
- dtech 2y agoThe pep explicitly adresses the use case, and it's still allowed. The point of the pep is that it should be explicit, especially because the short form doesn't show whether catching terminating exceptions is a bug or intentional
- _hl_ 2y agoWhat’s wrong with being explicit about “I really do mean anything that goes wrong” by catching the base class?
- BurningFrog 2y agoThat's actually the better way for me as well! So my comment is somewhat off topic. I still don't like the proposed change because of how much existing code it would break, but if we're designing a new language I approve.
- _hl_ 2y agoI see - I suppose that’s a fair viewpoint to have! I’m not much of a python programmer but my experience with the language would make me tend to agree actually. There are bigger fish to fry and so the effort to go after this relatively tiny sardine is perhaps not worth it.
- nomel 2y agoI don't understand this. To me, a bare exception is explicitly that. By not providing a specific exception, you're saying "nothing specific, literally anything".