On 7/29/05, Brett Cannon <[EMAIL PROTECTED]> 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
except Exception:
or
except Raisable:
depending on what they want.
> MacError
> UnixError
Do we really need these? Let's not add things that won't be used.
> NamespaceException
>
> 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?
> EnvironmentError
>
> 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).
> RuntimeError
> 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.
> IOError
>
> 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.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
