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

From: Jason Stewart (jstewart_at_[hidden])
Date: 2002-03-20 10:11:05

One of the original goals of this project was to make it easier to  write 
"script-like" programs. One of the things that makes it easy to write 
scripts in perl is that you can ignore things that are not important to 
you. I agree that it is a Good-Thing to force checking of errors and 
exceptions are a good way to do this. However, what Robert has suggested (I 
think) is two functions. One throws an exception if the file is not there, 
the other just returns success/failure. This meets both requirements above. 
It is possible to write robust programs and it is possible to write quick 
utilities.

Jason Stewart

At 09:48 AM 3/20/2002 -0500, you wrote:
> > 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.
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost