Re: [boost] Re: Re: [Filesystem] i18n

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-04-12 09:05:11

From: "Beman Dawes" <bdawes_at_[hidden]>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message 
> news:200504051942.j35JgJR05410_at_vanzandt.balstatdev.susq.com...
> > From: "Beman Dawes" <bdawes_at_[hidden]>
> >>
> > ...  The key is to understand that
> > is_directory() returns true iff the supplied pathname is a
> > directory to the caller.  That means it must exist, be
> > accessible, and be a directory.  Anything else isn't a directory,
> > so far as the caller is concerned.
> 
> If it is a CD-ROM, and a little slow to become ready (as happened to me 
> several times in experimenting with how Python handles these cases), it 
> really strikes me as stretching it to ignore the "Not ready" error. 
> Likewise, when working across a network, and the network goes down, to we 
> really want something that was a directory a second ago to become not a 
> directory?

In the latter case, on NFS, a script is blocked waiting for
the NFS server to come back.  That doesn't help with other
filesystems, of course, but, the idea is that a transient failure
could be handled by the library.  In the "Not ready" case, the
library could retry some number of times or for up to some number
of seconds (configurable values, of course).  If the retry period
is exceeded without resolving the problem, then just failing
rather than throwing an exception still works.

In the network down case, that's a hard error and, I suppose,
merits an exception.

> > Also, don't forget that with other, more detailed means to get
> > information on a pathname, like the stat() (or whatever you
> > choose to call it) function, one can get more precise information
> > if warranted by the code.
> 
> I'd rather require those who want to bypass error checks to use status().

Hmmm.  That's a reasonable argument.  Since there will be a means
to get the information without an exception, that could work.

> > I recall that your original notion for the Filesystem library was
> > to enable script-like coding in C++.  Such code is less rigorous
> > than normal applications.
> 
> I don't buy that. I've seen really seriously flawed data get shipped to 
> customers, doing untold harm to the business, because production scripts 
> ignored errors.

As Peter mentioned, returning false from is_xxx() is not ignoring
an error.  It is saying that at the moment, given the current
permissions and the current user's credentials, the supplied path
is no an xxx.  Since the filesystem is fluid anyway -- a
file/directory can be created, deleted, and modified at any time
-- you really can't count on much even with exceptions.

IOW, you have to write your code expecting that everything will
work as desired and when it doesn't, write sufficiently smart
error handling code or rely on the user to decipher the problem
with the current state of the filesystem.

For example, if I'm expecting to read a file and I cannot, I
typically report that fact and leave to the user the job of
figuring out what's wrong with the file or path to it.  That
approach is handled by a non-throwing is_xxx().

> >  That's not to say that it need be
> > sloppy, but it is often more forgiving.  I'll again refer to my
> > years of writing shell scripts on *nix.  The -d test never
> > generates a signal (the moral equivalent of an exception in C++
> > in this case); it just returns true or false.  That simplicity
> > makes it easier to write scripts, though I'll grant that it does
> > mean you have to be a little careful to not make too many
> > assumptions about what ! -d means.
> 
> That's fine, but the default should be to not ignore errors, rather than the 
> other way around, IMO.

As we've said, this doesn't ignore errors, it just classifies
them as cases that mean is_xxx() returns false.

> Also, my guess is that it is a little hard for most people to follow the 
> several aspects of this discussion that we think should result in changes to 
> the current library. Thus I may implement status(), recast exists() and the 
> is_x() functions in terms of status(), and try to come up with a firmer (and 
> testable) definition of what the status attributes mean (to answer Peter's 
> very valid concerns about exact meaning.)

That sounds like a good approach.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;