[Python-Dev] Exception masking/chaining

[Jeremy Hylton]

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