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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-19 16:17:25

From: Brey, Edward D [mailto:EdwardDBrey_at_[hidden]]
> 
> > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> > 
> > I think the "basic" remove() should not throw an exception for the
> > equivalent of ENOENT.  That is, if the postcondition is 
> > satisfied, then
> > remove() need not throw an exception, even if the file didn't 
> > exist when called.
> 
> Throwing only when the postcondition is false isn't really 
> broad enough.

It is for remove().

> For example, try applying the concept on copying a file.  Suppose the

I never intended to apply that approach to copying a file or any other file
operation.  It may map well to others, but probably won't.  That doesn't
mean it isn't appropriate for remove().

> destination file already exists and has the right contents 
> and attributes.
> OK not to throw?  Sometimes so.  But often, it is an indication that
> something has gone wrong (possibly quite a while in the 
> past), and it is

Having copy() check file sizes and attributes and then compare contents is
inappropriate.  That's a higher level of functionality.

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

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

Rob
Susquehanna International Group, LLP
http://www.sig.com