Antichecked exceptions
PEP 479 introduced this idea that basically boils down to raising your exceptions only when you mean it. Specifically: generators only raise StopIteration when they return/exit/terminate. And they prevent the user from raising it under other circumstances. Can we call this "antichecked exceptions"? Generators specifically check for StopIteration raised in undesired circumstances, and make sure they get wrapped. This is a form of runtime checking, so the "checked" part of the name makes sense. But this is unlike "checked exceptions", like those in java, that mostly just encourage uhh silently ignoring the exception? (And those are *statically* checked anyway...) So the prefix "anti" distinguishes it from that. Obviously this name is meant to be more broad than just the implementation of generators. (We made a pypi package that tries to expand on the concept.) But, thoughts? Naming things is powerful. (Is this the wrong list for this? Uhh like it's a name idea for a thing in python? But uhh... it's not so much a change proposal? Except to refer to it by this new name? But anyway...)
Soni L. writes:
Can we call this "antichecked exceptions"?
I don't see why not. Personally I'd prefer calling it "exception filtering" since it's not a property of the exception, but a pattern in the calling code. But I'm only -0 on "antichecked" and +0 on "filtered".
(Is this the wrong list for this?
It's not wrong. But unless you can get a more general PEP than 479, folks who feel like you do are going to have to watch All The Lists for different terminology, and propose "antichecked" in any threads where it comes up. A different term such as "checked exceptions" could establish itself while you're not looking.
participants (2)
-
Soni L.
-
Stephen J. Turnbull