On Thu, 2003-06-12 at 20:52, Guido van Rossum wrote:
But that is a different case. As I understand it, chaining would only occur if a second exception was raised *before* the current exception was caught -- e.g. if there's a bug in a piece of code in a finally block that's being executed while unwinding to find an exception handler.
Interesting.. I had never even thought of this case. I thought chaining was specifically when catching an exception and raising another in its place.
To the people who came up with the idea, which is it?
I don't know if I participated in the earlier email discussions. I do remember some conversations in the office here. I'm interested in chaining to convert one kind of exception to another. I was debugging a case that is illustrated by the example below.
class Foo: ... pass ... {}.update(Foo()) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: keys
I expected a TypeError in this case, because I've passed an object to dict.update that couldn't possibly work. I looked at changing the code to generated a TypeError, but I realized that the AttributeError keys is a lot more helpful for a developer who wants to understand what went wrong. I think chained exceptions could make this error message a bit clearer. The AttributeError could become an attribute (previous?) of the TypeError that is ultimately raised. I think there are relatively few places where chaining exceptions makes sense, so I'd like to see an explicit API for chaining. Code that wants to create chained exceptions would explicitly opt in. Jeremy