On Wed, Mar 23, 2016 at 6:43 AM, Michael Torrie <torr...@gmail.com> wrote: > And despite the impression you may have gotten, it is appropriate to > look before you leap. Using os.exists() and other pre-flight checks are > appropriate.
Hmm, can you justify this? Remember, as soon as any other process has done anything, your LBYL is invalid. You check that the file exists, then it gets deleted. Or you check that it doesn't, and bam, suddenly it does. The only way to be certain is to do an operation that enforces it on the hard disk itself - either open the file (after that, deletion can't affect you - on some OSes, deletion can't happen), or create it and hold it open exclusively (nobody else can create a file with that name). >> (4) Or if the user code does want to check for certain errors (like, >> File Not Found, by far the most likely, and so that it can deal with >> that and continue executing), it now has to go and dig out docs for ... >> what? The user code needs to know what is going on inside the supposedly >> opaque function it's calling. > > Good documentation should describe exactly what exceptions a function or > library raises and why. I tend to try to follow the example of Python's > standard library. I keep my exception classes few, and raise a good > error message with it. > > But often times the exceptions we're talking about are standard Python > exceptions arising from things like I/O, not custom library classes. If you have documentation like this, it should list only the exceptions that you explicitly raise, not those that can bubble up through it - this is where Java gets it wrong, IMO. If you attempt to read from a file that gets passed in as an argument, AttributeError could get raised, but you shouldn't document that; but if you have a line of code that says "raise InconsistentDNSRecordError", then yes, that's something worth documenting. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
