[Python-3000] New builtin exceptions classes?

Brett Cannon brett at python.org
Thu Mar 22 20:30:45 CET 2007


On 3/22/07, Frank Benkstein <frank-python at benkstein.net> wrote:
> Hi,
>
> I'm new to this list and interested in Python 3000 development.
>
> The following is not really a proposal that is ready to be implemented.
> I'm merely interested if this is a problem others want to be solved,
> too, and if it would be possible to get such a thing into Python 3000.
>
> IMHO Exceptions should carry more information about why and where the
> exception happened. A good example of an exception class carrying that
> kind of information is IOError with its 'filename' and 'errno'
> attributes (although these could be documented better). It would be
> nice if all builtin Exceptions had those kind of attributes. As an
> example KeyError could have a 'key' and a 'mapping' attribute,
> IndexError could have a 'index' and an 'sequence' attribute and so on.
> It is arguable if the second ones ('mapping' and 'sequence') are really
> needed, but I think it would be really nice to have those as it would
> make debugging a lot easier. Additionally they shouldn't really hurt
> because as per PEP 3110 exception instances are deleted when the
> exception handler is finished.
>
> A further addition to this proposal would be to discourage raising
> exceptions as wrappers around diagnostical messages. Currently it is
> very hard to programmatically find out what happened here:
>
> >>> int([])
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: int() argument must be a string or a number, not 'list'
>
> It would be nice if the recommended way would be something like the
> following, with only __str__ formatting the message:
>
> raise TypeError(
>     '%(target)s() argument must be one of %(allowed)s, not %(given)s',
>     target=int,
>     allowed=(str, int, float, long),
>     given=type(...))
>
> Maybe the the most common messages could be predefined in the Exception
> class instead of constructed ad-hoc to make processing easier but
> having them constructed as shown would already help a lot.
>

If you would like to try to come up with a more structured proposal
please bring it up on python-ideas.

-Brett


More information about the Python-3000 mailing list