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

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

> From: Stewart, Robert [mailto:stewart_at_[hidden]]

> Why is it so important to know that the file didn't exist 
> when remove() tried to remove it!

It depends on why you're removing it, of course.  Say you've called program
A to create a script, which you feed into program B, which you delete when
program B is done.  If you get to the delete, and the script file isn't
there, you know you're in trouble.  You wonder why program B didn't
complain.  Maybe A didn't put the file where you expected and B used
internal defaults.  Better to get a nice exception rather than have the
sequence silently "work".

Consider a utility that dumps your heap when a program exits.  If there is
something in your heap, you have a leak.  By the time the problem is
detected, there isn't any programmatic action that you can take to recover
from the error.  However, it is still valuable for diagnostics to have the
check in place.

Checking that a file that you expected to exist actually exists is likewise
useful for spotting bugs that may otherwise be hard to detect.

> This is fine, but I guess I'd name it "set_error_handler" and 
> it should
> return the previous handler.  The unfortunate thing is that 
> file_io_context
> would need to replicate the entire filesystem library 
> interface or vice
> versa (assuming the free functions would install a handler that throws
> exceptions after restoring the original handler).

Issues like this would need to be resolved.  I like your handler idea,
although I'd like something better than the return the last error handle
approach.  As far as duplication, that could be avoided by only providing
the functions within a context and having a default (global constant)
context that handles errors the same way that the free functions would.
 
> > 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
> 
> But you don't need to check it in most cases.

The need to check is a matter of degree.  I'd say that there is often a
"desire to check for diagnostic purposes".