Will Python exceptions be documented?

[John J. Lee]

vegard at mail.com (Vegard Bakke) writes:

> From whet I can see, Python documentation is lacking a very important
> piece of information.  Very few functions have documented what
> exceptions they raise, and under what cicumstances.  Is this a task on
> the schedule?

IIRC, yes.


[...]
> I have seen many different examples for catching exceptions from
> open(). Which is the right one?

What examples, specifically?  The docs say IOError can be raised.
Just about everything can raise ValueError, TypeError,
KeyboardInterrupt and MemoryError, so they aren't typically
documented.  I'm not sure exactly when WindowsError (rather than
something more specific) gets raised.

Not answering your question, but as a BTW: in that particular case, if
you're getting uncontrolled input you might sometimes want to
normalise the exceptions raised by catching everything but a few
exceptions.  This is useful because you might not have anticipated
every way that weird input might trip up your code (ie. your code may
be buggy).  See this recipe and my comment

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/101853


In fact, I didn't show the try / finally needed to close the file
there, so it should really be:

import traceback
from cStringIO import StringIO

DEBUG = True

def debug(msg):
    print msg

def load(filename):
    f = open(filename)
    try:
        try:
            # Some code that might raise IOError, or another exception that you
            # weren't expecting, if the user is imaginitive enough...
        except (AssertionError, KeyboardInterrupt, IOError):
            # NOTE WELL the brackets around the exception classes -- an except
            # with two arguments means something quite different!
            raise
        except:
            if DEBUG:
                f = StringIO()
                traceback.print_exc(None, f)
                debug("uncaught exception:\n%s" % f.getvalue())
            raise IOError, "invalid file '%s'" % filename
    finally:
        f.close()

load("/some/nonsense/file.txt")


> The error from function math.log(0) is a by unpredictable, but at
> least that is documentet.  What about all the others? math.asin(2),
> shutil, os, sys?
> 
> All know that asin(2) is wrong, but how do I know that ValueError is
> the exception I should catch, and how do I know that is the only one?
> (Sorry, try it is the wrong answere here.)

For the math module, the log(0) situation applies.  From the 2.3
library docs for the math module:

 Note: The math module consists mostly of thin wrappers around the
   platform C math library functions. Behavior in exceptional cases is
   loosely specified by the C standards, and Python inherits much of
   its math-function error-reporting behavior from the platform C
   implementation. As a result, the specific exceptions raised in
   error cases (and even whether some arguments are considered to be
   exceptional at all) are not defined in any useful cross-platform or
   cross-release way. For example, whether math.log(0) returns -Inf or
   raises ValueError or OverflowError isn't defined, and in cases
   where math.log(0) raises OverflowError, math.log(0L) may raise
   ValueError instead.


> My other issue with is concerning the documentation of the exceptions
> themselves. How can I find out that I can use 'filename', 'errno' and
> 'strerror' for the exception IOError without having to use
> dir(IOError())?  And is it valid in all versions/platforms?

That's documented under the base class, EnvironmentError.


> Since I'm critisising the lack of work, I will voulunteer to help out
> with the process. But I will need some guidance and pointers in the
[...]

Great.  I'd say just submit some specific doc patches with the
knowledge you already have (as long as you make it clear where you're
unsure).  Since that shows you're prepared to do some work on it, it's
likely to get you feedback from the people who know all the details
but don't have time to work on it themselves.  Of course, the core
people are probably particularly busy with 2.3 ATM, so don't expect a
rapid response.


John