[issue6210] Exception Chaining missing method for suppressing context

[Ethan Furman]

Ethan Furman <ethan at stoneleaf.us> 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 <report at bugs.python.org>
<http://bugs.python.org/issue6210>
_______________________________________