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

From: Brey, Edward D (EdwardDBrey_at_[hidden])
Date: 2002-03-20 09:48:28

> From: Stewart, Robert [mailto:stewart_at_[hidden]]
> 
> > useful to bail out and go into diagnostic mode.  The same 
> > argument can be
> > made for removal.  Often you can get by with ignoring the 
> > problem, but by
> > triggering an error and addressing it, you get the 
> > opportunity to dig in and
> > get to the bottom of an otherwise masked problem.
> 
> I never said we should ignore the condition.  I suggested 
> that remove()
> return an indicator as to whether the file was actually 
> remove() or didn't
> exist.  One can write code to inspect the return value if 
> that's condition
> is interesting.

The problems with requiring programmer to inspect the return value are
well-known and were a great motivation for the invention of exceptions.  I
think regressing to a check-the-return-code pattern would be a bad idea
unless we knew that it would be very rare when anyone cared.  However, I
think that in many applications, overall system robustness and diagnostics
would benefit from asserting that the remove was successful, and it would be
good to make this as easy for the programmer as possible, lest we be tempted
to be lazy and just skip it (ignore the return value).

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).

> > In my Python script for performing the formal builds of our 
> > software, I am
> > quite happy when the script throws an exception when I tell 
> > it to remove a
> > file that I expect should be there but isn't.  It's basically 
> > like getting a
> > free assertion in the code.
> 
> I'd hate having to write, or even execute code that ignores 
> an exception
> raised by such a common and (nearly always) benign condition. 
>  Throwing an exception is too heavyweight for something like this.

This is a good demonstration that there are at least two different use cases
for the file IO library.  Setting up try blocks for each remove is too much
coding.  Likewise, checking the return value from each remove is too much
coding.  Having a remove and a remove_if_exists helps, but it doesn't handle
the case where you want to be notified of the problem but not have it
interrupt the program flow.  For that you need an error notification
context.