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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-03-21 09:10:43

From: Brey, Edward D [mailto:EdwardDBrey_at_[hidden]]
> 
> > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> > > 
> > I don't buy it.  If this is important, program A will check 
> > to see that the
> > script exists before calling B.  If B doesn't complain about 
> > the script's
> > absence, then it isn't important to B.  When A regains 
> > control, it's only
> > concern is to ensure that the script no longer exists; no 
> > exception needed.
> 
> That approach works, too; however, it is more coding (plus 
> requires control
> over the design of B).  Since we need to delete the file anyway, it is
> convenient to bundle the existence check into the delete 
> call.  That way the
> algorithm is simply Call A, Call B, Delete File.  No 
> intermediate checks are
> needed, but there is still good diagnostics.  True, one can 

Here's pseudo-code for the two alternatives.

Approach 1: remove() returns a value to indicate that the file didn't exist

try
{
    create script
    if (exists(script))
    {
        run program B
        remove(script)
    }
    else
    {
        report missing script
    }
}
catch (???)
{
    diagnose problems creating script or running B
}

Approach 2: remove() throws an exception if the file didn't exist

try
{
    create script
    run program B
    remove(script)
}
catch (???)
{
    if (exception means that script was missing)
    {
        report missing script
    }
    else
    {
        diagnose problems creating script or running B
    }
}

Approach 3: like Approach 2, but unique exception

try
{
    create script
    run program B
    remove(script)
}
catch (remove's missing file exception)
{
    report missing script
}
catch (???)
{
    diagnose problems creating script or running B
}

Approach 1 and 2 have the same number of lines of code, as I format them.
Approach 3, if possible, requires three fewer lines of code, as I format
them.  However, Approach 1 makes clear that program B needs the script and
that the existence of the script is a prerequisite.  Neither Approach 2 nor
3 make that as obvious.

> live without
> this, just like one can live with a remove that always throws 
> on any error
> and lot of try/catch blocks.

Writing a "lot of try/catch blocks" is not a sign of good design.  Throwing
exceptions is expensive.  If a condition is not uncommon and is benign, then
throwing an exception is unwarranted.

> > > Checking that a file that you expected to exist actually 
> > > exists is likewise
> > > useful for spotting bugs that may otherwise be hard to detect.
> > 
> > Please give me good examples of this.  I can't think of one.
> 
> Such was the motivation for my above example.  If you want to get more

I realize that was your motivation, but I found it an uncompelling example.

> Presume that you are making a utility to wipe files.  You 
> overwrite the file
> many times and then delete it.  If for whatever reason the 
> delete fails, the
> user definitely should be notified of it.

If you cannot delete the file, that's a problem.  If the file doesn't exist,
there's no problem.  Before you ever got to the remove() call, you would
have overwritten the file "many times."  The code that overwrites the file
will have error handling code to notice that the file disappeared while
trying to overwrite it.  Provided that code successfully overwrote the file
the requisite number of times, it doesn't matter if the file is gone by the
time remove() is called.  The user doesn't need to know about that
condition.

> I'd take this a step further, and say that any time the user 
> asks to specify
> delete a file, he should be notified if the delete fails.  
> That gives him a
> heads up that his view of the file system is out of date 
> and/or there is
> some other entity (possibly previously unknown to him) 
> working with the same
> files as he.

If the user types a command that triggers a call to remove(), then yes, the
program will want to notify the user that the file was already gone.  If the
user selects a file in a GUI display of the filesystem and asks to delete
it, and by the time the GUI reacts to the UI events and makes the call to
remove() the file is gone, then no, I don't think you'd want to notify the
user.  Since the file was visible in the GUI, then the UI and the user
thought it existed.  When the "delete" operation is complete, if the file is
no longer in the filesystem, then the operation was successful, regardless
of whether the call to remove() actually removed the file or not.

I still see no compelling example requiring that remove() throw an exception
if the file does not exist.  The few examples that need to know that the
file didn't exist when remove() tried to remove it can simply check the
return value.  If it isn't important to the application to know about that
condition, then the application can ignore remove()'s return value safely.
Simple.

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