From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-03-19 12:03:40
> From: Stewart, Robert [mailto:stewart_at_[hidden]]
> I think the "basic" remove() should not throw an exception for the
> equivalent of ENOENT. That is, if the postcondition is
> satisfied, then
> remove() need not throw an exception, even if the file didn't
> exist when called.
Throwing only when the postcondition is false isn't really broad enough.
For example, try applying the concept on copying a file. Suppose the
destination file already exists and has the right contents and attributes.
OK not to throw? Sometimes so. But often, it is an indication that
something has gone wrong (possibly quite a while in the past), and it is
useful to bail out and go into diagnostic mode. The same argument can be
made for removal. Often you can get by with ignoring the problem, but by
triggering an error and addressing it, you get the opportunity to dig in and
get to the bottom of an otherwise masked problem.
In my Python script for performing the formal builds of our software, I am
quite happy when the script throws an exception when I tell it to remove a
file that I expect should be there but isn't. It's basically like getting a
free assertion in the code.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk