Re: Filesystem library: remove / etc

From: dylan_nicholson (dylan_nicholson_at_[hidden])
Date: 2002-03-18 16:56:24

--- In boost_at_y..., Beman Dawes <bdawes_at_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