On 7/29/05, Brett Cannon firstname.lastname@example.org wrote:
Well, it has been discussed at multiple times in the past and I have promised to write this PEP several times, so I finally found enough time to write a PEP on reorganizing exceptions for Python 3.0 .
Thanks for getting this ball rolling!
(I wonder what happened to Ping's PEP 344 -- he just dropped out, it seems.)
Below is some feedback.
Often people use a bare ``except`` when what they really wanted were non-critical exceptions to be caught while more system-specific ones, such as MemoryError, to pass through and to halt the interpreter. With a hierarchy reorganization, bare ``except`` clauses can be changed to only catch exceptions that subclass a non-critical exception superclass, allowing more critical exceptions to propagate to the top of the execution stack as was most likely intended.
I appreciate the attempt to make bare except: less dangerous by not catching certain exceptions, but I worry that these changes might actually make bare except: *more* likely to be used, which is contrary to the intention. Maybe we should just get rid of it, and encourage people to write
depending on what they want.
Do we really need these? Let's not add things that won't be used.
To provide a common superclass for exceptions dealing with namespace issues, this exception is introduced. Both UnboundLocalError and UnboundGlobalError (the new name for NameError) inherit from this class.
OTOH there's something to say to unify NameError and AttributeError, isn't there?
Originally meant as an exception for when an event outside of the interpreter needed to raise an exception, its use has been deemed unneeded. While both IOError and OSError inherited this class, the distinction between OS and I/O is significant enough to not warrant having a common subclass that one might base an ``except`` clause on.
-1000. Depending on whether you use open() or os.open() you'll get one or the other for pretty much the same thing.
Also, I think that socket.error and select.error should inherit from EnvironmentError (or maybe even from OSError).
Meant to be used when an existing exception does not fit, its usefulness is consider meager in Python 2.4 [exceptionsmodule]_. Also, with the CriticalException/Exception dichotomy, Exception or CriticalException can be raised directly for the same use.
-0.5. I use it all the time as the "application" exception in apps (scripts) that are too small to define their own exception hierarchy.
StopIteration and GeneratorExit
Inherit from ControlFlowException.
Collecting all control flow-related exceptions under a common superclass continues with the theme of maintaining a hierarchy.
Yes, but how useful it this? I don't expect to ever come across a situation where I'd want to catch both, so this is more for organization of the docs than for anything else.
IMO a good principle for determining the ideal exception hierarchy is whether there's a use case for catching the common base class.
No longer subclasses EnvironmentError.
-1000, see above.
Change the Name of Raisable?
It has been argued that Raisable is a bad name to use since it is not an actual word [python-dev1]_.
Then we'll make it a word. Is Java's equivalent, Throwable, any more a word? In this case I like the parallel with Java.
Should Bare ``except`` Clauses be Removed?
Yes, see above.