From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-08-03 12:54:44
At Saturday 2002/08/03 05:16, you wrote:
>From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
> > At Friday 2002/08/02 21:23, you wrote:
> > >Yes. Using the other function is dangerous. It provides a false sense of
> > >security by working in all testcases, then throws an exception in the
> > >when some other process gets in and deletes the file before we get a
> > >chance. Precondition checking should usually not be done with exceptions
> > >the first place, and I think this is a particularly bad use for it.
> > >[deleted]
> > >This example is much worse, since the problem will almost never show up
> > >during testing, and even if it did, there's absolutely no test you can
> > >to check whether the file will actually exist by the time you try to
> > >it.
> > It means that if the OS won't tell you whether it actually deleted the
> > file, the program won't know for sure.
> > You might not even be able to tell then (not all OS's report with
> > one-to-one correspondence with the truth).
>Please give two examples of a program that needs to delete a file and which
>cares not only that the file has been deleted, but that its own call to the
>OS was the one responsible for the deletion.
It's possible I missed a turn in the conversation. I thought the example
of being able to establish that a file had actually been deleted instead of
simply being "not currently available", previously elucidated, sufficient.
How about a system administration program which is supposed to be the only
program which manages a set of files. A file "gone walkies" would be a
concern of possible system intrusion.
> David Abrahams * Boost Consulting
>dave_at_[hidden] * http://www.boost-consulting.com
Victor A. Wagner Jr. http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
"There oughta be a law"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk