Ethan Furman <[email protected]> added the comment:
> 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.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue6210>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
