On Fri, Apr 8, 2011 at 10:11 AM, Guido van Rossum <guido@python.org> wrote: <snip>
- Quite independently, I think it is time that we started documenting which exceptions are raised from standard APIs. The trick is to avoid overdocumenting: there is no point in documenting that everything can raise MemoryError or that passing in wildly invalid arguments can raise TypeError or AttributeError (and pretty much anything else). But the variety of exceptions that may be raised by something like urlopen, depending on which layer of the network and I/O stacks detects a problem are worth documenting. Maybe this example could even be a starting point for a rationalization of some of the exceptions involved. (And if we find there are legitimate situations where a networking or I/O problem raises a "generic" error such as TypeError or AttributeError, those are probably bugs that should be fixed in the code.)
This would be very nice.
- Lastly, there is a bunch of standard exception types that are usually caused by bad code (as opposed to bad data or an environmental problem). This would include NameError, TypeError, AttributeError, but not KeyError, IndexError, ValueError. Perhaps it makes sense to introduce a common base class for these "bad code" exceptions? Unlike the other exception types, I think that the set of "bad code" exceptions is pretty much static; a new library module is not going to define raise a new kind of "bad code" exception. (But it may well define a new kind of "bad data" exception, and I don't think we need a common base class for all "bad data" or "bad state" exceptions.)
I actually like both the BadCode exception and the BadData exception. Geremy Condra