Suggesting the use of StandardError as base of error Exceptions.

Antoon Pardon apardon at forel.vub.ac.be
Mon Mar 6 11:08:17 CET 2006


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.

-- 
Antoon Pardon



More information about the Python-list mailing list