Walter D=F6rwald wrote:
>=20
> An open question for exception chaining was which exception type is
> tested in the except statement, the innermost or the outermost one.
>=20
> I'd say for backwards compatibility reasons this should be the outermos=
t
> 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:
>=20
> class spam:
> def __getitem__(self, index):
> if index=3D=3D42:
> raise TypeError
> return None
>=20
> x =3D filter(None, spam())
>=20
> this might give:
>=20
> Traceback (most recent call last):
> File "spam.py", line 8, in ?
> x =3D filter(None, foo())
> File "spam.py", line 4, in __getitem__
> raise TypeError("ouch")
> TypeError: ouch
> Info: in filter() at index 42
>=20
So have a function that takes the current exception, stores it as an=20
attribute of a new one, and have exception-handling code no of the=20
possible existence of the attribute and print out the info if it exists?
-Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4