Exception Handling in Python 3

[Ethan Furman]

MRAB wrote:
> 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.

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~