On 8/3/05, Nick Coghlan <[EMAIL PROTECTED]> 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). >
Does no one else feel some of the names could be improved upon? While we might all have gotten used to them I still don't believe newbies necessarily grasp what they are all for based on their names. Then again, if this PEP is viewed more as handling macro issues with the currnt hierarchy and name changes can be done when we get closer to Python 3.0 I am happy to drop renaming until we are closer to actual implementation with a section just listing suggested name changes and stating that they are just being considered possibl renaming which will not be finalized until we are closer to Python 3.0 . > I like James's suggestion that instead of trying to switch people to using > something other than "except Exception:", we just aim to adjust the hierarchy > so that "except Exception" becomes the right thing to do. Changing the > inheritance structure a bit is far easier than trying to shift several years > of accumulated user experience. . . > > Anyway, with the hierarchy below, "except Exception:" still overreaches, but > can be corrected by preceding it with "except (ControlFlow, CriticalError): > raise". > > "except Exception:" stops overreaching once the links from Exception to > StopIteration and SystemExit, and the links from StandardError to > KeyboardInterrupt, SystemError and MemoryError are removed (probably difficult > to do before Py3k but not impossible). > > This hierarchy also means that inheriting application and library errors from > Exception can continue to be recommended practice. Adapting the language to > fit the users rather than the other way around seems to be a pretty good call > on this point. . . > Well, then StandardError becomes kind of stupid. The only use it would serve is a superclass for all non-critical, non-control-flow built-in exceptions. I really don't know how often that is going to be needed. I do realize it keeps inheritance working for existing code, though. I guess that would just have to be a trade-off for backwards-compatibility. OK, I am convinced; I will revert back to Raisable/Exception instead of Exception/StandardError. -Brett _______________________________________________ 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
