Suggesting the use of StandardError as base of error Exceptions.

Discussion in 'Python' started by Antoon Pardon, Mar 6, 2006.

  1. 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
    Antoon Pardon, Mar 6, 2006
    #1
    1. Advertising

  2. 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...read/thread/56d7c5767a205866/d2403ae0c6267ca1


    Diez
    Diez B. Roggisch, Mar 6, 2006
    #2
    1. Advertising

  3. Antoon Pardon

    Kent Johnson Guest

    Diez B. Roggisch wrote:
    > Antoon Pardon schrieb:
    >> 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.


    It's PEP 352, it's already done. This will be in Python 2.5. It's good
    to see that the time machine is stil working ;)
    http://www.python.org/peps/pep-0352.html

    Kent
    Kent Johnson, Mar 6, 2006
    #3
  4. Antoon Pardon wrote:
    > 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()


    You've already been pointed to `PEP 352`_, but just to highlight the
    salient point, I believe what you want to write is::

    try:
    ...
    except (KeyboardInterrupt, SystemExit):
    raise
    except:
    ...

    ... _PEP 352: http://www.python.org/peps/pep-0352.html

    STeVe
    Steven Bethard, Mar 6, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rim
    Replies:
    20
    Views:
    697
    Corey Coughlin
    Jul 8, 2003
  2. Jordan Rastrick
    Replies:
    22
    Views:
    632
    Oren Tirosh
    Mar 27, 2005
  3. Replies:
    11
    Views:
    426
  4. mttc
    Replies:
    9
    Views:
    320
    Martien Verbruggen
    Nov 25, 2008
  5. Steven D'Aprano

    StandardError in Python 2 -> 3

    Steven D'Aprano, Nov 17, 2012, in forum: Python
    Replies:
    1
    Views:
    141
    Ian Kelly
    Nov 17, 2012
Loading...

Share This Page