Identifying exceptions that can be raised

[Roy Smith]

Peter Hansen <peter at engcorp.com> wrote:

> For example, the other day I discovered that if you attempt
> to read or write from/to a closed file, you don't get what
> you might expect (an IOError or an OSError), but in fact
> you get a ValueError.  Writing unit tests was what led to
> this discovery.  (Perhaps it's actually documented... I don't
> know and didn't bother looking.)

What you are describing is essentially black-box testing.  It may be a 
valid procedure for QA purposes, but it's hardly a reasonable way to 
write a program.  Actually, it's worse than black-box testing.  
Black-box testing says you should design your tests based only on the 
documentation (functional spec, whatever) without looking at the source 
code.  You're saying you should write the code without even looking at 
the documentation.

I'm a big fan of test-driven development, but not to the extent that I 
feel I can ignore reading the documentation to see how something is 
supposed to work.  It took me about 15 seconds to find the page in the 
library reference for file objects, where I immediately found:

---------
close()
 Close the file. A closed file cannot be read or written any more.  Any 
operation which requires that the file be open will raise a  ValueError 
after the file has been closed. Calling  close() more than once is 
allowed.
---------

Computer Science is not an experimental science.  In the old days of 
biology, if I wanted to know what a certain gene did, I made my best 
guess and designed an experiment to prove or disprove my theory.  Repeat 
as long as the funding holds out.  These days, I pop the DNA into a 
sequencing machine and read the source code.  We may not fully 
understand the language the program is written in, but it sure beats 
poking at the thing with a stick and seeing what happens.