![]() |
Will Python exceptions be documented?
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? In my opinion, every function that might raise an exception should state so explicitly in the documentation, even uncaught exceptions from a subfunction. I have seen many different examples for catching exceptions from open(). Which is the right one? 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.) 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? 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 beginning. Python is too good to have a B+ documentation. We can do better. Cheers, Vegard -- Vegard Bakke My spelling is wobbly. It's good spelling, but it wobbles, and the letters get it the wrong places. Winnie the Pooh :wq |
Re: Will Python exceptions be documented?
vegard@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/Coo.../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 |
| All times are GMT. The time now is 05:15 PM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.