Re: Exception Handling in Python 3

Discussion in 'Python' started by Chris Rebert, Oct 24, 2010.

  1. Chris Rebert

    Chris Rebert Guest

    On Sat, Oct 23, 2010 at 10:01 PM, Steve Holden <> wrote:
    > I was somewhat surprised to discover that Python 3 no longer allows an
    > exception to be raised in an except clause (or rather that it reports it
    > as a separate exception that occurred during the handling of the first).

    <snip>
    > Give the traceback I expected and wanted in Python 2:
    >
    > Traceback (most recent call last):
    >  File "<stdin>", line 4, in <module>
    > AttributeError: No attribute 'nosuch'
    >
    > but in Python 3.1 the traceback looks like this:
    >
    > Traceback (most recent call last):
    >  File "<stdin>", line 2, in <module>
    > KeyError: 'nosuch'
    >
    > During handling of the above exception, another exception occurred:
    >
    > Traceback (most recent call last):
    >  File "<stdin>", line 4, in <module>
    > AttributeError: No attribute 'nosuch'
    >
    > Modifying the code a little allows me to change the error message, but
    > not much else:

    <snip>
    > What
    > is the correct paradigm for this situation?


    There doesn't seem to be one at the moment, although the issue isn't
    very serious. Your Traceback is merely being made slightly longer/more
    complicated than you'd prefer; however, conversely, what if a bug was
    to be introduced into your exception handler? Then you'd likely very
    much appreciate the "superfluous" Traceback info.

    Your quandary is due to the unresolved status of the "Open Issue:
    Suppressing Context" in PEP 3141
    (http://www.python.org/dev/peps/pep-3134/ ). I guess you could start a
    discussion about closing that issue somehow.

    Cheers,
    Chris
    --
    http://blog.rebertia.com
     
    Chris Rebert, Oct 24, 2010
    #1
    1. Advertising

  2. Chris Rebert wrote:
    > Your Traceback is merely being made slightly longer/more
    > complicated than you'd prefer; however, conversely, what if a bug was
    > to be introduced into your exception handler? Then you'd likely very
    > much appreciate the "superfluous" Traceback info.


    I think what's disturbing about this is that the two halves of
    the extended traceback are printed in the wrong order. We're
    all used to looking down the bottom of the traceback to see
    where the error originated, but with the new format, that point
    is buried somewhere in the middle.

    --
    Greg
     
    Gregory Ewing, Oct 29, 2010
    #2
    1. Advertising

  3. Chris Rebert

    Chris Rebert Guest

    On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
    <> wrote:
    > Chris Rebert wrote:
    >>
    >> Your Traceback is merely being made slightly longer/more
    >> complicated than you'd prefer; however, conversely, what if a bug was
    >> to be introduced into your exception handler? Then you'd likely very
    >> much appreciate the "superfluous" Traceback info.

    >
    > I think what's disturbing about this is that the two halves of
    > the extended traceback are printed in the wrong order. We're
    > all used to looking down the bottom of the traceback to see
    > where the error originated, but with the new format, that point
    > is buried somewhere in the middle.


    True, but swapping the order would only worsen Steve's problem. Most
    of his users presumably won't care about the underlying KeyError and
    would rather be presented with the AttributeError as the proximate
    "origin", despite that being technically inaccurate in the way you
    suggest. Six of one, half dozen of the other though.

    Cheers,
    Chris
     
    Chris Rebert, Oct 29, 2010
    #3
  4. Chris Rebert

    MRAB Guest

    On 29/10/2010 11:24, Chris Rebert wrote:
    > On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
    > <> wrote:
    >> Chris Rebert wrote:
    >>>
    >>> Your Traceback is merely being made slightly longer/more
    >>> complicated than you'd prefer; however, conversely, what if a bug was
    >>> to be introduced into your exception handler? Then you'd likely very
    >>> much appreciate the "superfluous" Traceback info.

    >>
    >> I think what's disturbing about this is that the two halves of
    >> the extended traceback are printed in the wrong order. We're
    >> all used to looking down the bottom of the traceback to see
    >> where the error originated, but with the new format, that point
    >> is buried somewhere in the middle.

    >
    > True, but swapping the order would only worsen Steve's problem. Most
    > of his users presumably won't care about the underlying KeyError and
    > would rather be presented with the AttributeError as the proximate
    > "origin", despite that being technically inaccurate in the way you
    > suggest. Six of one, half dozen of the other though.
    >

    I've just come across the same problem myself.

    I wanted to raise an exception that would be more meaningful to the
    caller, but the traceback included info on the original exception,
    which is an implementation detail.

    I understand that it can be useful, but IMHO there should be a simple
    way of suppressing it.
     
    MRAB, Oct 29, 2010
    #4
  5. Chris Rebert

    Ethan Furman Guest

    MRAB wrote:
    > On 29/10/2010 11:24, Chris Rebert wrote:
    >> On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
    >> <> wrote:
    >>> Chris Rebert wrote:
    >>>>
    >>>> Your Traceback is merely being made slightly longer/more
    >>>> complicated than you'd prefer; however, conversely, what if a bug was
    >>>> to be introduced into your exception handler? Then you'd likely very
    >>>> much appreciate the "superfluous" Traceback info.
    >>>
    >>> I think what's disturbing about this is that the two halves of
    >>> the extended traceback are printed in the wrong order. We're
    >>> all used to looking down the bottom of the traceback to see
    >>> where the error originated, but with the new format, that point
    >>> is buried somewhere in the middle.

    >>
    >> True, but swapping the order would only worsen Steve's problem. Most
    >> of his users presumably won't care about the underlying KeyError and
    >> would rather be presented with the AttributeError as the proximate
    >> "origin", despite that being technically inaccurate in the way you
    >> suggest. Six of one, half dozen of the other though.
    >>

    > I've just come across the same problem myself.
    >
    > I wanted to raise an exception that would be more meaningful to the
    > caller, but the traceback included info on the original exception,
    > which is an implementation detail.
    >
    > I understand that it can be useful, but IMHO there should be a simple
    > way of suppressing it.


    I agree. It seems to me that the suppression should happen on the raise
    line, so that we aren't losing the extra information if an actual error
    occurs in the error handler.

    ~Ethan~
     
    Ethan Furman, Oct 29, 2010
    #5
  6. Chris Rebert

    Greg Ewing Guest

    Chris Rebert wrote:
    > On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
    > <> wrote:


    >>I think what's disturbing about this is that the two halves of
    >>the extended traceback are printed in the wrong order. We're


    > True, but swapping the order would only worsen Steve's problem.


    Yes, I can see that what Steve's problem requires is a way
    of explicitly saying "replace the current exception" without
    attaching any context.

    However, in the case where the replacement is accidental,
    I think it would make more sense to display them in the
    opposite order. Both of the exceptions represent bugs in
    that situation, so you will want to address them both, and
    you might as well get the traceback in a non-confusing order.

    --
    Greg
     
    Greg Ewing, Oct 30, 2010
    #6
    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. damacy
    Replies:
    8
    Views:
    599
    Dennis Lee Bieber
    Aug 22, 2006
  2. MarkE
    Replies:
    0
    Views:
    685
    MarkE
    Mar 27, 2007
  3. Mark Tarver
    Replies:
    22
    Views:
    1,382
    J Kenneth King
    Apr 26, 2009
  4. Peter
    Replies:
    34
    Views:
    2,020
    James Kanze
    Oct 17, 2009
  5. VSK
    Replies:
    0
    Views:
    268
Loading...

Share This Page