From: "Beman Dawes" <bdawes@acm.org>
"Rob Stewart" <stewart@sig.com> wrote in message news:200504051942.j35JgJR05410@vanzandt.balstatdev.susq.com...
From: "Beman Dawes" <bdawes@acm.org>
... 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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;