Will Python exceptions be documented?

Re: Will Python exceptions be documented?

vegard@mail.com (Vegard Bakke) writes:
[color=blue]
> 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?[/color]

IIRC, yes.


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

What examples, specifically? The docs say IOError can be raised.
Just about everything can raise ValueError, TypeError,
KeyboardInterru pt 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




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 , KeyboardInterru pt, 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")

[color=blue]
> 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.)[/color]

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.

[color=blue]
> 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?[/color]

That's documented under the base class, EnvironmentErro r.

[color=blue]
> 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[/color]
[...]

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