[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
rrr at ronadam.com
Wed Aug 3 18:33:31 CEST 2005
Nick Coghlan wrote:
> Phillip J. Eby wrote:
>>+1. The main things that need fixing, IMO, are the need for critical and
>>control flow exceptions to be distinguished from "normal" errors. The rest
>>is mostly too abstract for me to care about in 2.x.
> I guess, before we figure out "where would we like to go?", we really need to
> know "what's wrong with where we are right now?"
> Like you, the only real problem I have with the current hierarchy is that
> "except Exception:" is just as bad as a bare except in terms of catching
> exceptions it shouldn't (like SystemExit). I find everything else about the
> hierarchy is pretty workable (mainly because it *is* fairly flat - if I want
> to catch a couple of different exception types, which is fairly rare, I can
> just list them).
More often than not, 9 out 10 times, when ever I use "except Exception:"
or a bare except:, what I am doing is the equivalent to:
<statement that may fail> # will either fail or not
Usually I end up using "if hasattr():" or some other way to pre test the
statement if possible as I find "except: pass" to be ugly. And putting
both the statement that may fail together with the depending statements
in the try:, catches too much. Finding subtle errors hidden by a try
block can be rather difficult at times.
Could inverse exceptions be an option? Exceptions don't work this way
so it would probably need to be sugar for "except <exception>:pass; else:".
<statement that may fail>
except not <a_exception>: "except None:" as an option?
Ok, this isn't exactly clear, and probably a -2 for several reasons.
The exception tree organization should also take into account inverse
relationships as well. Exceptions used for control flow are often of
the type "if not exception: do something".
More information about the Python-Dev