Exception Handling in Python 3
ethan at stoneleaf.us
Fri Oct 29 19:56:28 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.
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.
More information about the Python-list