Message124820
> 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. |
|
Date |
User |
Action |
Args |
2010-12-28 21:42:54 | ethan.furman | set | recipients:
+ ethan.furman, rhettinger, ncoghlan, pitrou, draghuram, mrabarnett, steven.daprano, poke |
2010-12-28 21:42:54 | ethan.furman | set | messageid: <1293572574.25.0.407430453891.issue6210@psf.upfronthosting.co.za> |
2010-12-28 21:42:52 | ethan.furman | link | issue6210 messages |
2010-12-28 21:42:52 | ethan.furman | create | |
|