Walter Dörwald wrote:
An open question for exception chaining was which exception type is tested in the except statement, the innermost or the outermost one.
I'd say for backwards compatibility reasons this should be the outermost exception,
That's what I was thinking. Simpler and no surprises for old code.
but we could add a new feature to that: Add a new exception subclass named Info that can be used to wrap exceptions without influencing the type of the exception raised. This could be used by code higher up in the call chain to add information to the exception without changing the type that gets caught in the except statement. For example filter() could be changed to add information about the iteration index where the exception happened:
class spam: def __getitem__(self, index): if index==42: raise TypeError return None
x = filter(None, spam())
this might give:
Traceback (most recent call last): File "spam.py", line 8, in ? x = filter(None, foo()) File "spam.py", line 4, in __getitem__ raise TypeError("ouch") TypeError: ouch Info: in filter() at index 42
So have a function that takes the current exception, stores it as an attribute of a new one, and have exception-handling code no of the possible existence of the attribute and print out the info if it exists? -Brett