Exception Handling in Python 3

MRAB python at mrabarnett.plus.com
Fri Oct 29 19:19:23 CEST 2010

On 29/10/2010 11:24, Chris Rebert wrote:
> On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
> <greg.ewing at canterbury.ac.nz>  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.

More information about the Python-list mailing list