Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-02 23:23:28


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 provided.
Am
> 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 field
when some other process gets in and deletes the file before we get a
chance. Precondition checking should usually not be done with exceptions in
the first place, and I think this is a particularly bad use for it.

I used to work on a project that manipulated timestamped events. Events
were always marked with positive times. The functions for erasing events in
a timerange accepted signed numbers denoting times, but would assert if the
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 (a
very common case), you had to remember to pin the start time at zero or you
might get an assertion. It was a crapshoot whether a failure to do so would
turn up during testing. It usually would, though, and you could easily fix
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 use
this boilerplate all over, but at least there was a formula to make things
work.

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 make
to check whether the file will actually exist by the time you try to delete
it.

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk