Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-03 16:05:04

At 12:23 AM 8/3/2002, David Abrahams wrote:

>From: "Beman Dawes" <bdawes_at_[hidden]>
>> Again, the function remove_all() is provided to meet the need for a
>> function which does not throw an exception if the target doesn't exist.
>> It seems to me people are advocating something that is already
>> I missing something?
>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

My experience (and I'm talking a lot of years here working on systems with
a lot of money riding on them) is that remove() errors do show up a great
deal in testing, particularly early in a new system's life-cycle.

It is definitely a pain to analyze these during programming, or during
early testing if the analysis wasn't done during programming, and figure
out which are serious.

The payoff comes later, when the system goes into production in the field
and there is a serious screw up, like the one you describe where someone
runs another process in a directory they shouldn't be in. I've been
rewarded enough times for having included remove() error checking that it
has stuck in my mind as a worthwhile practice. It seemed like the remove()
check was often the first sign of impending disaster. Since even on
today's processors these jobs take 12-24 hours, the operations people love
it when you can detect an error early rather than late.

> Precondition checking should usually not be done with exceptions in
>the first place, and I think this is a particularly bad use for it.

But as James Dennett points out, the error conditions the library throws
really aren't exactly precondition failures, they are failures the
operating system is reporting.

I guess you could view the file not existing, or being read-only, or your
process not having the right permissions, etc, as being precondition
failures, but because of the shared resource non-atomic operation issues, I
don't think that is the best approach.

>I used to work on a project that manipulated timestamped events. Events
>were always marked with positive times. The functions for erasing events
>a timerange accepted signed numbers denoting times, but would assert if
>start time was ever negative, since no events were allowed to have a
>negative time (see: "you're not allowed to delete a file that doesn't
>exist"). If the time range to be deleted was the result of a computation
>very common case), you had to remember to pin the start time at zero or
>might get an assertion. It was a crapshoot whether a failure to do so
>turn up during testing. It usually would, though, and you could easily
>the problem by inserting a stupid call to max(start, 0) in order to keep
>the assertion brasswork shiny. It was immensely frustrating to have to
>this boilerplate all over, but at least there was a formula to make
>This example is much worse, since the problem will almost never show up
>during testing,

That's contrary to a lot of real-world experience I've had. In fact the one
argument that resonates with me in favor of ignoring a return code of
"couldn't find the file you asked the OS to delete" is that otherwise
remove() generates a lot false positives, particularly during early

> and even if it did, there's absolutely no test you can make
>to check whether the file will actually exist by the time you try to

The general solution is to go ahead and try the operation, and see if the
operating system reports success or not.


Boost list run by bdawes at, gregod at, cpdaniel at, john at