RE: [boost] Re: Filesystem library: remove / etc

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-20 11:25:49

At 09:48 AM 3/20/2002, Brey, Edward D wrote:

 >What makes this dilemma trickier than most is that often, even though we
 >want to know about the problem, we don't really want to interrupt our
 >control flow.  That is, we want to limp on as best as we can.  That's not
 >the case in my Python build script, since I can always spawn another 
build
 >which cleans up anyway, but a program that is exiting wants to do the 
best
 >cleanup that it can.
 >
 >To solve this problem, I propose that the file IO functions be nested in 
a
 >error notification context.  Basically, it would be like this:
 >
 >class file_io_context {
 > public: // Setup
 >   void set_listener(  void (* listener)(error_type)   );
 >
 > public: // File manipulation
 >   void remove(string filename);
 >};
 >
 >Now if remove fails, it calls the registered listener.  Likewise there
 >could
 >be states variables set as to which errors are reported and/or throw, if
 >such flexibility is necessary (I'm not sure).

My initial reaction is that errors are best handled by the traditional 
exception mechanism, but I'll try to keep an open mind.

Part of the rationale for Predicate versions of some of the composite 
operations like prunes/copies is that users can express exactly what files 
to work on.  For example, prune( "my_dir", !is_read_only(_1) ), if 
read-only files should be skipped.

--Beman