This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan.furman
Recipients draghuram, ethan.furman, mrabarnett, ncoghlan, pitrou, poke, rhettinger, steven.daprano
Date 2010-12-28.21:42:52
SpamBayes Score 2.90281e-06
Marked as misclassified No
Message-id <>
> Besides, if you are writing library code (as opposed to application
> code), you shouldn't care at all how tracebacks are displayed, should
> you?

I care when it lies:

During handling of the above exception, another exception occurred:

This is a blatant falsehood -- another exception did not occur, a different exception was raised.

Now, when another exception does actually occur, I'm all for the nested traceback, but if I'm raising a different one, why is this useful:

--> d.address
Traceback (most recent call last):
  File "", line 7, in __getattr__
ValueError: tuple.index(x): x not in tuple

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 9, in __getattr__
    raise AttributeError("Attribute %s does not exist" % name)
AttributeError: Attribute address does not exist


Furthermore, I use my own library, and have no interest in seeing extra, completely unnecessary, and wrong (verbiage, anyway) traceback info -- not in my own libraries, nor in other's that I may be using.

Keep the nesting for when an exception actually occurs, not for when an exception is, under programmer control, being modified/changed.
Date User Action Args
2010-12-28 21:42:54ethan.furmansetrecipients: + ethan.furman, rhettinger, ncoghlan, pitrou, draghuram, mrabarnett, steven.daprano, poke
2010-12-28 21:42:54ethan.furmansetmessageid: <>
2010-12-28 21:42:52ethan.furmanlinkissue6210 messages
2010-12-28 21:42:52ethan.furmancreate