Antoon Pardon schrieb: > In a number of cases I have a program that looks like the following. > > for case in all_cases: > try: > treat(case) > except Exception, ErrInfo: > generate_traceback() > > The idea is to get as much information as possible when something > goes wrong but at the same time treat as many cases as possible. > > Then one day things broke. The reason was that in some circumstances > treat would decide that things were beyond control and called sys.exit > However sys.exit doesn't return to the O.S. immediately but raises > SystemExit, which was caugth by the code and the loop continued. > > I then took a look at http://docs.python.org/lib/module-exceptions.html > which describes the exception heirarchy as follows: > > Exception > +-- SystemExit > +-- StopIteration > +-- StandardError > | + > | + All kind of error exceptions > | + > +---Warning > + > + All kind of warnings > + > > and came to the conclusion, that it would be better to write my code > as follows: > > for case in all_cases: > try: > treat(case) > except StandardError, ErrInfo: > generate_traceback() > > Unfortunatly this doesn't work either because a lot of the error > exceptions in the stdlib (if not all) inherit directly from > Exception instead of from StandardError. The documentation also > seems to suggest this use for users exception. > > Now I was wondering if it wouldn't be better that for exception > that indicate some error condition that these would inherit > from StandardError and that this would be indicated in the > documentation and reflected in the stdlib? > > Would it break much code to make this change? My first impression > would be no, but I could be missing something.
There has been a discussion on this just a few days ago, have you read that? There is even a PEP mentioned. http://groups.google.com/group/comp.lang.python/browse_thread/thread/56d7c5767a205866/d2403ae0c6267ca1 Diez -- http://mail.python.org/mailman/listinfo/python-list
