--- In boost@y..., Beman Dawes <bdawes@a...> wrote:
>
<snip>

> The convenience functions, besides providing recursion, regular
expression
> and other filtering, and similar commonly needed features, will
also treat
> errors in the context of typical use. Thus remove() resulting in
ENOENT
> wouldn't throw an exception, for example.
>
From what I've seen on this thread, of all the different scenarios in
which various remove failures can be safely ignored, none stand out
as so common as needing their own "convenience" function. As it is,
it's 4-5 lines of code to write your own wrapper around what boost
provides. Just for the record, most of the times I have used remove,
I've literally not cared at all whether there was an error, no matter
what it was. The "file in use" error in particular is one that I
know I can safely ignore (sometimes I might retry a couple of times).
But to start picking and choosing arbitrarily which errors should
throw exceptions seems a questionable task at this stage anyway. The
first cut of the library can get by fine with just a 'remove' that
throws exceptions on all possible errors - if there really is a
strong demand for one that avoid some exceptions, then we can look at
it then. And it may not be just remove - it's conceivable that other
filesystem operations need similar treatment.

As for the temporary file case, there's actually a good argument for
a RAII-style "temporary file" and "temporary directory" class (I've
used them quite a bit myself). As it is I don't think there has been
a proprosal to support things like tmpnam etc.

Dylan