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 <1293572574.25.0.407430453891.issue6210@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 "nested_exceptions.py", line 7, in __getattr__
    return self.data[self.names.index(name)]
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 "nested_exceptions.py", 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.
History
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: <1293572574.25.0.407430453891.issue6210@psf.upfronthosting.co.za>
2010-12-28 21:42:52ethan.furmanlinkissue6210 messages
2010-12-28 21:42:52ethan.furmancreate