On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
<greg.ew...@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.
--
http://mail.python.org/mailman/listinfo/python-list
